Timestamp bugs with files dated before the Unix epoch

Comments, questions, bug reports, etc.
Post Reply
chungy
Posts: 30
Joined: Mon Feb 15, 2016 3:40 am

Timestamp bugs with files dated before the Unix epoch

Post by chungy »

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.
synchronicity
Site Admin
Posts: 472
Joined: Sun Aug 02, 2015 10:31 pm

Re: Timestamp bugs with files dated before the Unix epoch

Post by synchronicity »

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.
chungy
Posts: 30
Joined: Mon Feb 15, 2016 3:40 am

Re: Timestamp bugs with files dated before the Unix epoch

Post by chungy »

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