Directory with pre-1970 timestamps fails on Windows
Happy new year! To celebrate this time-related festival, here is a time-related bug in Meld… :-)
When I use the Windows build of Meld to compare directories containing files whose modification times are before 1970 (in other words, their time since the epoch is negative), the comparison silently aborts. An example screenshot is shown below.
In this example, the files in all the directories are binary identical and have the same time stamps. (The time stamps of the directories are different because they are not preserved when they are copied.) The file COLTAB1
has a modification time of 1851-01-19 09:37:50. I'm not sure why it's that old, perhaps part of a copy protection mechanism - this is on an image of a disk from an old Windows 3.1 machine from the early 1990's.
This is Meld 3.18.2 on Windows 10 Pro x64.
Some other situations I tried:
- Linux with Meld 3.18 (using WSL on Windows) - did NOT have a problem
- Windows with Meld 3.18, and a file with modification date of 1968 (not so far in the past) - same problem.
- Windows with Meld 3.18 with modification date of 2999 (way into the future past the 2030 limit) - did NOT show the problem.
So it seems that negative timestamps and Windows are both required.
A couple of other observations:
- If I run Python,
import os.path
and then useos.path.getmtime()
onCOLTAB1
, it correctly reports the timestamp as-3753712064.0
. - I notice that Meld uses PyGObject, but the glib documentation for
g_stat()
warns that it uses_stat32()
on 32-bit Windows, and the Microsoft documentation for_stat()
-like functions says that none of them support dates before 1970. I guess that Meld is not using this given that the 2999 timestamp works. - I found at least one place in the Meld source code (as of 3.19) where
-1
was being used as a dummy value to "no timestamp". I didn't test this specifically, but it seems like this would mean that any file that actually has this timestamp would have problems. If so, this is a near-duplicate of #244 (closed).
Here is the screenshot:
Here is a listing of the directory expanded in the left pane. The corresponding directory in the right hand pane has the same files. What's more, the other subdirectories (CANDY
, DESSERT
, ...) show up as empty despite also containing files.
d:\src\_misc\meld>dir d:\data\supertmp\a\WORMS\DATA\BEACH\
Volume in drive D is Data
Volume Serial Number is CCC1-9823
Directory of d:\data\supertmp\a\WORMS\DATA\BEACH
2018-12-30 17:36 <DIR> .
2018-12-30 17:36 <DIR> ..
1851-01-19 06:12 1,024 COLTAB1
1995-08-26 13:47 18,723 LAND1
2 File(s) 19,747 bytes
2 Dir(s) 768,501,903,360 bytes free