X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org Date: Wed, 12 Jan 2011 11:47:44 +0100 From: Corinna Vinschen To: cygwin@cygwin.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@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <3501944D149644D394474781054F5E98@multiplay.co.uk> <4D2783A3.5000008@redhat.com> <4D27C896.30202@cygwin.com> <265F601A437E4A03BE8C665BE7470721@multiplay.co.uk> <4D27D66F.8030201@cygwin.com> <4D28F1AC.1070907@laposte.net> <20110111095435.GF3413@calimero.vinschen.de> <4D2C7024.8090507@redhat.com> <20110112102823.GF6353@calimero.vinschen.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@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.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