This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange fstatat / stat behavour on directories causing tar "file changed as we read it" error


On Jan 12 08:01, Eric Blake wrote:
> On 01/12/2011 03:47 AM, Corinna Vinschen wrote:
> > 
> > On second thought, let's take a step back.
> > 
> > Actually, directories can change all the time.  Why on earth is tar
> > checking the st_size member of a directory at all?  That's a bug IMO.
> > No application should do that.  I understand that a change in the inode
> > number points to the fact that the directory has been replaced
> > underfoot, but why should tar be concerned that a directory has changed
> > its size while it's reading files from it?  I mean, even during a tar
> > backup, there's no reason to expect that files are *not* added or
> > deleted to a directory by other applications, and these actions may
> > naturally change the size of the directory.
> 
> When tar is trying to capture the entire contents of the directory, any
> modification to that directory (including adding a file to the directory
> which changes the st_size of the directory) means that tar missed
> something, so tar emits a warning to tell you about that fact.

I see where you're heading to, but it appears to me that this is bound
to produce a lot of unnecessary warnings.  When tar backs up a
directory, it backs up the state of the directory when it starts to
opendir it.  The implicit expectation that the directory doesn't change
underfoot is a bit borderline, isn't it?  I'm wondering if the tar
developers are aware of the extra burden due to puzzled users of the new
version.  Previous tar's were already quite talkative.

> > Having said that, I don't think it's correct to change Cygwin here.
> > It's just a bug in tar.
> 
> I'm not sure we've established that point yet, but I'll raise the
> question upstream.  But, assuming tar is doing the right thing...
> 
> >  The fact that the directory size changes even
> > if the content hasn't changed is just a side effect of the OS MO.  It
> > doesn't matter if the directory has actually changed or not.  It's not
> > in the hand of a single application.
> 
> then cygwin's behavior DOES matter to tar - no other system changes the
> st_size of a directory without ALSO adding or deleting files within that
> directory and also updating the st_mtim of the directory; at which point
> tar is entirely within its rights to complain (the directory changed
> while trying to read it, so the tar file may be incomplete).  Locking
> st_size at 0 avoids the issue entirely, whether or not upstream tar
> agrees that checking changes in st_mtim but ignoring changes in st_size
> would be a more appropriate behavior.

The fact that a directory change will also change st_mtime is a good
point.  That's obviously not the case in the observed scenario.
However, a call to touch could have done that.  But I see the point.
st_ctime is a more reliable candidate for this kind of test and it
will also not be changed.


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]