X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 12 Jan 2011 16:20:01 +0100
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: Strange fstatat / stat behavour on directories causing tar "file changed as we read it" error
Message-ID: <20110112152001.GD12190@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <D43AAA42D53E47AF958054385DAEFB50 AT multiplay DOT co DOT uk> <4D27C896 DOT 30202 AT cygwin DOT com> <265F601A437E4A03BE8C665BE7470721 AT multiplay DOT co DOT uk> <4D27D66F DOT 8030201 AT cygwin DOT com> <4D28F1AC DOT 1070907 AT laposte DOT net> <20110111095435 DOT GF3413 AT calimero DOT vinschen DOT de> <4D2C7024 DOT 8090507 AT redhat DOT com> <20110112102823 DOT GF6353 AT calimero DOT vinschen DOT de> <20110112104744 DOT GH6353 AT calimero DOT vinschen DOT de> <4D2DC23E DOT 5040202 AT redhat DOT com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <4D2DC23E.5040202@redhat.com>
User-Agent: Mutt/1.5.21 (2010-09-15)
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT com>
List-Subscribe: <mailto:cygwin-subscribe AT cygwin DOT com>
List-Archive: <http://sourceware.org/ml/cygwin/>
List-Post: <mailto:cygwin AT cygwin DOT com>
List-Help: <mailto:cygwin-help AT cygwin DOT com>, <http://sourceware.org/ml/#faqs>
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
Delivered-To: mailing list cygwin AT cygwin DOT com

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