Re: [Bug-tar] listed-incremental broken in 1.25 on Solaris 10

[Markus Duft]

On 02/02/11 20:28, Paul Eggert wrote:
> On 02/01/11 23:28, Markus Duft wrote:
>> i don't think it's "only" a bug in the filesystem

Hey!

i know it has been a while, but i came back to the problem today...

> 
> Yes, most likely it isn't "just" a bug in the file system.
> tar has changed the way that it sets file time stamps,
> in order to avoid certain security holes.  It now sets
> the before closing the file rather than after.  Most
> likely your file system is buggy, and 'close' is mistakenly
> changing the file's time stamp to the wrong value.

i think it's not close(). i think it happens while flushing the buffers to 
disk, and i saw it happen on various file systems as soon as the load is high 
enough, so that contents may not yet be flushed to the disk when setting the 
timestamp (so flushing during close re-sets it).

> 
> We can't simply revert the change in tar, because
> that would reintroduce the security holes.  However, perhaps
> there is a way to work around the problem on buggy file systems.
> 
> One possibility is to invoke fsync(fd) just before close(fd).
> Perhaps you can try that, on your buggy system, to see if
> that works around the problem.  For performance reasons,
> we'd only want to do fsync on buggy file systems, but the
> first step is to see whether fsync works around the bug
> at all.

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. 
would it be ok to commit this patch? otherwise tar doesn't work too well on 
interix, really...

Regards, Markus

tar-1.26-interix.patch
Description: Text Data