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
