Mail Archives: cygwin/2011/01/12/10:20:37
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
- Raw text -