X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Wed, 12 Jan 2011 11:47:44 +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: <20110112104744.GH6353@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <3501944D149644D394474781054F5E98 AT multiplay DOT co DOT uk> <4D2783A3 DOT 5000008 AT redhat DOT com> <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>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
In-Reply-To: <20110112102823.GF6353@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 11:28, Corinna Vinschen wrote:
> On Jan 11 07:58, Eric Blake wrote:
> > On 01/11/2011 02:54 AM, Corinna Vinschen wrote:
> > > I can not reproduce the effect, at least not on W7, but apparently it
> > > happens on some systems.  So, given that the directory size is
> > > irrelevant for all practical purposes anyway, and given that there's no
> > > application which has problems with a directory size of 0, should Cygwin
> > > just always set st_size to 0 for directories?  Independent of the
> > > underlying FS?
> > 
> > Always returning 0 size for all directories, regardless of FS, is
> > certainly the simplest workaround.  I'd say go for it.
> 
> What I'm missing is the information if the allocation size is
> affected as well.  You can't see that when using ls(1), but you
> can by using stat(1).  So, here's the question:
> 
> 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
> 
> ?

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.

Having said that, I don't think it's correct to change Cygwin here.
It's just a bug in tar.  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.


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