wimlib

Posted: **Tue Apr 18, 2017 1:49 am**

Two different behaviors can be observed on both Windows and Linux with timestamps set before 1970-01-01 00:00:00 UTC. Setup for testing is pretty simple (I used Cygwin on Windows, there might be a more native solution to manipulating timestamps, but regardless):

Code: Select all

mkdir timestamps
TZ=UTC touch -d "1970-01-01 00:00:00" timestamps/file1
TZ=UTC touch -d "1969-12-31 23:59:59" timestamps/file2

Then just capture the directory. The 1970 file (Unix epoch) has its timestamp properly represented in the wim file, while the 1969 one has two behaviors depending on the OS that captured it. On Windows, it has no write/access time stored at all, but on Linux, it shows a date far into the future (in the year 60425, to be exact). I suspect it's an issue related to the timestamp having a sign (the 1969 file is -1 seconds from the Unix epoch), and this is observed with wimlib 1.11.0.

Posted: **Wed Apr 19, 2017 7:28 am**

Thanks for reporting this! Yes, negative UNIX timestamps were not being handled correctly. Specifically, they seem to have been getting stored correctly, but were not being extracted or displayed correctly. I also found that the 32-bit Windows build of wimlib had additional problems caused by using 32-bit time_t instead of 64-bit time_t. All these bugs should be fixed in wimlib v1.12.0-BETA1.

Posted: **Wed Apr 19, 2017 11:46 am**

Oh, excellent, I don't have to recreate the archive I have that exhibited the problem. Thanks for fixing this!

wimlib

Timestamp bugs with files dated before the Unix epoch

Timestamp bugs with files dated before the Unix epoch

Re: Timestamp bugs with files dated before the Unix epoch

Re: Timestamp bugs with files dated before the Unix epoch