Re: [Bug-tar] interix timestamp issues (was: listed-incremental broken in 1.25 on Solaris 10)

[Markus Duft]

On 05/12/11 05:41, Paul Eggert wrote:
> On 05/11/11 01:49, Markus Duft wrote:
>> fsync(fd) before setting the timestamp helps, and i have a 1.26 patch 
>> (attached),
>> for now limited to interix only, although i saw it on linux too.
> 
> Can you describe the GNU/Linux scenario?  That would be a serious
> file system bug.  There are known bugs when running glibc compiled
> against newer headers but on older Linux kernels, but tar should
> work around those bugs; see gnu/futimens.c.  Why isn't that
> happening for you?

sad enough, i can't; it did happen one or two times since 1.25 on linux when 
handling large archives when the machine was under high load... i have a 
colleague @gentoo.org which had problems on NFS. i skimmed through gnulibs 
fdutimensat.c, and there is a fsync() call for NFS explicitly, which should 
avoid this problem. was it there with 1.25...? checking ... hm, yes, it was. 
strange, maybe HAVE_BUGGY_NFS_TIME_STAMPS should have been defined, when it 
wasnt.

> 
> Which system call is being used in Interix?  Is it futimens,
> or utimensat, or what?  Sorry, I've lost context.

uhm ... i start to see the problem here :) on interix, there is no system call 
to set the modification time on an open handle. it is rather set using 
utime[s]() (which one doesn't matter for this, i guess - newer interix have 
utimes(), but don't expose it through headers, and older ones don't have it).

hm. i tried to do nearly the same fix as for the NFS timestamps, and i realized 
that the fd in fdutimensat is 4, whereas in utimens, which is then called from 
somewhere in there, it is -1, so i can't do a fsync() in there (maybe the 
reason why NFS sometimes didn't work, too?).

i now have a new patch (attached), which syncs in fdutimensat when futimens 
failed, and the fallback to utimensat is used. this could have possibly been a 
problem on other filesystems too, right? (provided the system is dump enough to 
not have any futime* calls, which essestially should boil down to interix, and 
maybe one or two others ...? ;)).

i cc'ed gnulib folks, to hear what they have to say to my patch... hey folks 
*wink* :)

> 
> The workaround you sent doesn't look quite right.  Surely the fix
> belongs in the implementation of fdutimensat, not in just one of its
> callers.  And there must be something faster than calling fsync.
> Did you try the fix that Eric Blake suggested in
> <http://lists.gnu.org/archive/html/bug-tar/2011-02/msg00004.html>?

no, and i actually cant, as there is no system call to set timestamps on open 
fd's, and i think the problem actually boils down to this fact..

> 
> Finally, to answer your earlier question, it's clearly a filesystem
> bug.  I could cite POSIX chapter and verse on this, but I'd rather
> use a common sense argument: what's the point of having a system call
> like futimens if closing the file erases the work that futimens does?
> 

heh, right, and i don't have futimens, so.... ;)

regards, markus

tar-1.26-interix.patch
Description: Text Data