All of lore.kernel.org
 help / color / mirror / Atom feed
From: "René Scharfe" <l.s.r@web.de>
To: m@sph3r3.com
Cc: Junio C Hamano <gitster@pobox.com>, git@vger.kernel.org
Subject: Re: [PATCH] archive-zip: omit UT extra field if mtime is out of range
Date: Mon, 12 Oct 2026 16:45:12 +0200	[thread overview]
Message-ID: <0334c031-56e3-4c8d-8adc-52051d2e26aa@web.de> (raw)
In-Reply-To: <CA+h9NxRQLP=20kfmSm6B2WtkkmHDCfdRDZEawOpzFF1LoghTEA@mail.gmail.com>

On 10/12/26 2:56 PM, m@sph3r3.com wrote:
> Thanks for the patch. I confirmed that it fixes the 2106 case: before
> the change, UT wrapped to zero and unzip -u retained the existing 2025
> file; afterward, UT is omitted and the file is replaced correctly.

Thanks for checking!

> For the i386 failure Junio reported, the beyond-2038 archive test and
> its dependent omission check should use TIME_T_IS_64BIT. TIME_IS_64BIT
> checks Git's timestamp_t, which can be 64-bit while time_t is 32-bit.
> 
> With that two-line adjustment, all 18 t5004 tests pass on x86-64
> Linux. Forcing TIME_T_IS_64BIT off skips only those two tests; the
> other 16 pass, including both INT32_MAX checks. I haven't run a native
> 32-bit build.
That would be an easy way out, nice!  I suspect git archive should not
even use time_t in this context, though.

René


  reply	other threads:[~2026-10-12 14:45 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-05 13:48 [BUG] ZIP timestamp conversion and strict fast-import date validation Matthew E. Luallen
2026-10-05 19:49 ` René Scharfe
2026-10-05 20:32   ` Matthew E. Luallen
2026-10-07 15:33     ` René Scharfe
2026-10-06  3:22   ` m
2026-10-11 16:06 ` [PATCH] archive-zip: omit UT extra field if mtime is out of range René Scharfe
2026-10-12  2:08   ` Junio C Hamano
2026-10-12 14:39     ` René Scharfe
2026-10-12 12:56   ` m
2026-10-12 14:45     ` René Scharfe [this message]
2026-10-12 15:07     ` Junio C Hamano

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0334c031-56e3-4c8d-8adc-52051d2e26aa@web.de \
    --to=l.s.r@web.de \
    --cc=git@vger.kernel.org \
    --cc=gitster@pobox.com \
    --cc=m@sph3r3.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.