I still don't think ZIP /U works correctly

[vefatica]

ZIP /V reports UTC times. Is ZIP /U comparing a local time (on-disk file) to a UTC time (in-zip file).

If Alpengreis is east of UTC I can see how he gets older files replacing newer ones.

This one should have been updated (I rebuild the DLL since zipping it the last time).

p:\4wt\x64\release> zip /v 4wt.zip
2024-04-10  21:35        150,528   50%  4wt.dll

p:\4wt\x64\release> dir /k /m 4wt.dll
2024-04-10  17:56         149,504  4wt.dll

p:\4wt\x64\release> zip /u 4wt.zip 4wt.dll

p:\4wt\x64\release> zip /v 4wt.zip
2024-04-10  21:35        150,528   50%  4wt.dll

 

[Alpengreis]

Here, it works correctly:

d:\_tests\ziptest>zip ziptest.zip freetype.dll
<= D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>zip /v ziptest.zip
2024-03-15  16:37        654’336   45%  freetype.dll

d:\_tests\ziptest>dir /k /m freetype.dll
11.04.2024  17:32         654’341  freetype.dll

d:\_tests\ziptest>zip /u ziptest.zip freetype.dll
<= D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>zip /v ziptest.zip
2024-04-11  15:32        654’341   45%  freetype.dll

 

[vefatica]

Yes, but the original zipped file was weeks old.

You're in UTC+2, right? I doubt it would work if you updated the zipped file within 2 hours of its last update.

I may be off by an hour depending on whether (and when) Switzerland observes Daylight Saving Time.

 

[Alpengreis]

Yes UTC+2 ... I understand what you mean - yes, that could be the reason. Will make a new test and write the result here then ... thank you for the clever hint.

 

[Alpengreis]

It works too, see here:

d:\_tests\ziptest>dir /k /m freetype.dll
11.04.2024  21:30         654’516  freetype.dll

d:\_tests\ziptest>zip ziptest.zip freetype.dll
<= D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>zip /v ziptest.zip
2024-04-11  19:30        654’516   45%  freetype.dll

d:\_tests\ziptest>dir /k /m freetype.dll
11.04.2024  21:33         655’924  freetype.dll

d:\_tests\ziptest>zip /u ziptest.zip freetype.dll
<= D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>zip /v ziptest.zip
2024-04-11  19:33        655’924   46%  freetype.dll

 

[vefatica]

In another thread you said ZIP /U was adding files that were older (were you able to reproduce that?). That's what I'm trying to test. I think a better test would be this. I can't do it because I'm on the wrong side of UTC.

1. Zip the file
2. TOUCH the file with a time 30 minutes before it's current time (the file is now older than the one in the zipfile)
3. ZIP /U the file

This is what I think will happen. If the file's write time is 11:00 (local) and you ZIP it, ZIP /V will report 09:00 (UTC). If you then TOUCH the file with time 10:30, it's now older than it was, but ZIP /U will compare 10:30 (local) to 09:00 (zip's UTC time) and update it.

 

[Alpengreis]

That in the other tread is in combination with /R only (reproducable) which is not supported through the zip library. However, you are right, see here:

d:\_tests\ziptest>touch /t22:00 freetype.dll
11.04.2024 22:00:00.000  D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>dir /k /m freetype.dll
11.04.2024  22:00         655’924  freetype.dll

d:\_tests\ziptest>zip ziptest.zip freetype.dll
<= D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>zip /v ziptest.zip
2024-04-11  20:00        655’924   46%  freetype.dll

d:\_tests\ziptest>touch /t21:30 freetype.dll
11.04.2024 21:30:00.000  D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>dir /k /m freetype.dll
11.04.2024  21:30         655’924  freetype.dll

d:\_tests\ziptest>zip /u ziptest.zip freetype.dll
<= D:\_Tests\ziptest\freetype.dll

d:\_tests\ziptest>zip /v ziptest.zip
2024-04-11  19:30        655’924   46%  freetype.dll

So that is a bug I would say! OOR could be also wad (see my next posting) ...

 

[Alpengreis]

@rconn

Is that a bug OR is that WAD because zip uses UTC?

 

[Alpengreis]

Fixed with build 21.

Thank you, Rex!