[filesystem] Failures on FAT32

Hi all, there are two failures reported for the intel-win32-8.1 toolset (both in operations_test): http://tinyurl.com/5dbla After some investigation I've found out now that the tests fail only because they are run on a FAT32 disk! It was just coincidence that the failures popped up in the Intel 8.1 tests (...and it's quite amusing to say that we would need another toolset dimension for the filesystem :) ) Anyway, here some analysis (the second failure seems to be a general design problem!): First failure: operations_test.cpp(287): test time_diff >= 0.0 && time_diff < 60.0 failed --> the actual difference is -2! Second failure: std::exception: boost::filesystem::last_write_time ("wrong parameter") last_write_time contains this code: ::utimbuf buf; buf.actime = std::time_t(); ^^^^^^^^^^^^^ buf.modtime = new_time; This means that the last access (!) time is set to 1970-01-01-... when the last write time is changed by this call! IMO that's absolutely incorrect because it's a side effect which I'm sure the user wouldn't expect to happen! Furthermore - a nice coincidence again - it seems not to be allowed to set this early access time for FAT32. I didn't investigate too much, but what I can say for sure is that it works to set an access time of this year, but not for 1970 (-> results in an error "wrong parameter"). Stefan

At 12:18 PM 10/8/2004, Stefan Slapeta wrote:
Hi all,
there are two failures reported for the intel-win32-8.1 toolset (both in operations_test): http://tinyurl.com/5dbla
After some investigation I've found out now that the tests fail only because they are run on a FAT32 disk! It was just coincidence that the failures popped up in the Intel 8.1 tests (...and it's quite amusing to say that we would need another toolset dimension for the filesystem :) )
These same two failures have also shown up on some other platforms from time-to-time. There is apparently a new debug mode assert in VC++ 8.0 which is firing due to the second error.
Anyway, here some analysis (the second failure seems to be a general design problem!):
The second error is actually a really stupid typo in my original code that just happens to result in valid C++ that compiles (but does the wrong thing). I must have looked at that code five times in the last year, but didn't spot the typo until I read your message. See below.
First failure:
operations_test.cpp(287): test time_diff >= 0.0 && time_diff < 60.0 failed
--> the actual difference is -2!
I'll change the test to plus or minus 60 seconds.
Second failure:
std::exception: boost::filesystem::last_write_time ("wrong parameter")
last_write_time contains this code:
::utimbuf buf; buf.actime = std::time_t(); ^^^^^^^^^^^^^
That was meant read: buf.actime = std::time(0) (The same typo appears later in the code, too.) Now, it may be a poor design to update actime to the current time. It might be better to do a stat(), and get st_atime, and then use that. Opinions? Thanks, --Beman

Beman Dawes wrote: [...]
That was meant read:
buf.actime = std::time(0)
funny :)
Now, it may be a poor design to update actime to the current time. It might be better to do a stat(), and get st_atime, and then use that. Opinions?
IMO the really poor design is that of ::utime which forces you to set both the access time and the write time in the same call; I'm afraid you have no choice but to determine the actual access time before (as you suggested) :( Stefan

At 06:38 PM 10/8/2004, Stefan Slapeta wrote:
Beman Dawes wrote:
[...]
That was meant read:
buf.actime = std::time(0)
funny :)
Now, it may be a poor design to update actime to the current time. It might be better to do a stat(), and get st_atime, and then use that. Opinions?
IMO the really poor design is that of ::utime which forces you to set both the access time and the write time in the same call;
Yes, that's for sure.
I'm afraid you have no choice but to determine the actual access time before (as you suggested) :(
I've committed the changes to CVS. Thanks, --Beman
participants (3)
-
Beman Dawes
-
Stefan Slapeta
-
Stefan Slapeta