Re: seconds bug in dir()
- Posted by jimcbrown (admin) Apr 09, 2010
- 1211 views
however there is a known issue when using the FAT filesystem. the space used to store the date-time only allows room for a 2-second resolution
On Windows, Euphoria uses the Watcom library for this functionality but we could recode that to explicitly use the Windows API, however even then the problem will still exist for FAT filesystems.
1) Problem occurs on Windows XP, NTFS filesystem.
2) Not sure I fully buy this explanation: the problem is not that I somehow know that I saved a file at 18:03:19, but rather that Windows Explorer/API tells me that, yet dir() tells me 18:03:20, for the exact same file.
FYI, this causes the fairly obvious problem in Edita, as 18:03:20!=18:03:19, I rescan the file, and re-save the last modified time as 18:03:19, ad nauseum.
An acceptable alternative to fixing dir() would be a demo showing how to fudge the results from Windows API to /always/ match those from Watcom/dir()...
Regards, Pete
The issue is with the way the seconds field is calculated for watcom.
From be_machine.c, Dir() (the 2/3 version):
obj_ptr[9] = (direntp->d_time & 0x01F) << 1;
with direntp being a struct dirent pointer as returned by watcom's readdir() function. A "<< 1" is simply a multiplication by 2 so it seems that watcom's time resolution (at least via readdir() ) is only as good as 2 seconds and no finer...
Watcom supports the stat() function, so we may be able to use the Unix Dir() implementation on Watcom as well, instead of having two separate Dir() implementations... I think that would fix this bug.
