X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Thu, 13 Jan 2011 15:07:39 +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: <20110113140739.GD25033@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <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> <20110112152001 DOT GD12190 AT calimero DOT vinschen DOT de>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20110112152001.GD12190@calimero.vinschen.de>
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 16:20, Corinna Vinschen wrote:
> On Jan 12 08:01, Eric Blake wrote:
> > 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.

I've checked in a patch with sets st_size to 0 for all directories,
except on NFS, which hopefully isn't affected by this problem.


However, there's still the question I already asked yesterday.
Can somebody who can reproduce the issue test this?


I'm missing the information if the allocation size is affected as well.
You can see that when using stat(1).

For a directory which changes size in one of the observed scenarios,
what does stat print?  Does it look like this:

  $ stat weird_dir | grep Size
  Size: 0               Blocks: 0          IO Block: 65536  directory
  $ stat weird_dir | grep Size
  Size: 4096            Blocks: 4          IO Block: 65536  directory

or does it look like this:

  $ stat weird_dir | grep Size
  Size: 0               Blocks: 4          IO Block: 65536  directory
  $ stat weird_dir | grep Size
  Size: 4096            Blocks: 4          IO Block: 65536  directory

?


Thanks,
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