1. seconds bug in dir()
- Posted by petelomax Apr 09, 2010
- 1216 views
Can anyone confirm there is still a bug in dir() (r3132), which has been present since at least 2.4 and probably before that, whereby it randomly adds 1 or 2 seconds to the file times?
2. Re: seconds bug in dir()
- Posted by DerekParnell (admin) Apr 09, 2010
- 1225 views
Can anyone confirm there is still a bug in dir() (r3132), which has been present since at least 2.4 and probably before that, whereby it randomly adds 1 or 2 seconds to the file times?
I haven't looked into this however there is a known issue when using the FAT filesystem. The problem there is that the space used to store the date-time for a file only allows room for a 2-second resolution. That means that the recorded time for a file can be incorrect by up to two seconds.
On Windows, Euphoria uses the Watcom library for this functionality but we could recoded that to explicitly use the Windows API, however even then the problem will still exist for FAT filesystems.
3. Re: seconds bug in dir()
- Posted by petelomax Apr 09, 2010
- 1182 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
4. Re: seconds bug in dir()
- Posted by jimcbrown (admin) Apr 09, 2010
- 1210 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.
5. Re: seconds bug in dir()
- Posted by DerekParnell (admin) Apr 10, 2010
- 1177 views
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.
Ok, let's give it a try and failing that we use the Windows API directly. Can you do the coding as I find it very hard to test in my linux set up (involves a LOT of set up work first).
6. Re: seconds bug in dir()
- Posted by jimcbrown (admin) Apr 10, 2010
- 1139 views
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.
Ok, let's give it a try and failing that we use the Windows API directly. Can you do the coding as I find it very hard to test in my linux set up (involves a LOT of set up work first).
The change is three one-liners... all of which involve #ifdef changes only..
// 2 implementations of dir() #ifdef EWATCOM // 2 of 3: WATCOM method
becomes
// 2 implementations of dir() #if 0 //def EWATCOM // 2 of 3: WATCOM method
then
#endif #if defined(EUNIX) || defined(EMINGW) // 3 of 3: Unix style with stat() static object Dir(object x)
becomes
#endif #if defined(EUNIX) || defined(EMINGW) || defined(EWATCOM) // 3 of 3: Unix style with stat() static object Dir(object x)
and finally
#if defined(EMINGW) #define full_name_size (MAX_FILE_NAME + 257) #else #define full_name_size (MAX_FILE_NAME + NAME_MAX + 1) #endif
becomes
#if defined(EMINGW) || defined(EWATCOM) #define full_name_size (MAX_FILE_NAME + 257) #else #define full_name_size (MAX_FILE_NAME + NAME_MAX + 1) #endif
If this breaks on watcom (e.g. you get a compile error) then we should look at using a pure w32api Dir() on watcom.
7. Re: seconds bug in dir()
- Posted by DerekParnell (admin) Apr 10, 2010
- 1101 views
If this breaks on watcom (e.g. you get a compile error) then we should look at using a pure w32api Dir() on watcom.
I tried this but the watcom compiler still forces the file times to a 2-second resolution.
And BTW you needed another change ...
#if defined(EWATCOM) #include <sys/stat.h> #endif
I'll try using the Windows API next.
8. Re: seconds bug in dir()
- Posted by jimcbrown (admin) Apr 10, 2010
- 1115 views
If this breaks on watcom (e.g. you get a compile error) then we should look at using a pure w32api Dir() on watcom.
I tried this but the watcom compiler still forces the file times to a 2-second resolution.
That's extremely discouraging. I wonderhow watcom implements these functions internally.
9. Re: seconds bug in dir()
- Posted by DerekParnell (admin) Apr 10, 2010
- 1137 views
That's extremely discouraging. I wonderhow watcom implements these functions internally.
Yes it is ... I looked into the Watcom source and it uses the DOS interrupt #714E rather than the Windows API!
