On 02/04/2011 01:51 AM, Paul Eggert wrote: > On 02/02/11 23:48, Markus Duft wrote: >> which filesystem is _not_ buggy in this sense? > > I haven't run into the problem myself. I normally > use RHEL 5.5 + NFS, or Solaris 10 + NFS, or Ubuntu 10.10 > + ext4. But I haven't been looking for the problem > either. > > Do you have a small test case that > reproduces the problem? We should add it to the > GNU tar test cases. That will help us find out.
the case where this happens on interix is simple - a single file in an archive, which gets the wrong date when extracting. On linux, it seems that a very large archive, with very many files could trigger the problem, but not sure of that. i now know that on linux, it happens on NFS... but badly reproducible. i yesterday discussed the issue with some other developers from my company; we came to the conclusion, that most likely a close would not write timestamps as long as there is no data to write (thats why the fsync() solution works), but that will only be the case when the OS/FS is fast enough with flushing data. i know that windows is sooooo slow, which explains why i hit the issue all the time (and why the issue goes away if i wait a sec in a breakpoint before setting timestamps). linux/solaris/whatever will likely hit the issue only when under high load - is this possible? just my thoughts ;) markus
