X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=-1.5 required=5.0 tests=AWL,BAYES_00,FREEMAIL_FROM,RCVD_IN_DNSWL_LOW,SARE_FREE_WEBM_LAPOSTE,TW_RW,TW_WX,TW_XR,T_RP_MATCHES_RCVD,T_TO_NO_BRKTS_FREEMAIL
X-Spam-Check-By:	sourceware.org
Message-ID:	<4D28F1AC.1070907@laposte.net>
Date:	Sun, 09 Jan 2011 00:22:20 +0100
From:	Cyrille Lefevre <cyrille DOT lefevre-lists AT laposte DOT net>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 5.1; fr; rv:1.8.1.3) Gecko/20070326 Thunderbird/2.0.0.0 Mnenhy/0.7.5.666
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: Strange fstatat / stat behavour on directories causing tar "file changed as we read it" error
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>
In-Reply-To:	<4D27D66F.8030201@cygwin.com>
X-me-spamlevel:	not-spam
X-me-spamrating:	36.000000
X-me-spamcause:	OK, (-100)(0000)gggruggvucftvghtrhhoucdtuddrfedutddrtdegucetggdotefuucfrrhhofhhilhgvmecuoehnohhnvgeqnecuuegrihhlohhuthemuceftddtnecuucdlqddutddtmd
X-IsSubscribed:	yes
Mailing-List:	contact cygwin-help AT cygwin DOT com; run by ezmlm
List-Id:	<cygwin.cygwin.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

Le 08/01/2011 04:13, Larry Hall (Cygwin) a =C3=A9crit :
>=20
> On 1/7/2011 9:39 PM, Steven Hartland wrote:
>=20
> <snip>
>=20
>> Here it takes about 2 - 5mins for what ever is causing the 0 size after a
>> find to start to happen. Prior to that after the find all dirs show
>> 8192 for
>> size in an ls.
>=20
> Ah, that's interesting.  I see no such time-lag here.
>=20
<snip>
it seems to depend on the number of the entries the directory has.

Cyrille AT nowhere ~/somewhere/cvs
v2$ ls -ld
drwxrwsr-x+ 1 Cyrille         None       0 Feb 15  2007 .

Cyrille AT nowhere ~/somewhere/cvs
v2$ ll
total 128
drwxrwsr-x+ 1 Cyrille None 8192 Sep 10 20:00 CVSROOT
drwxrwsr-x+ 1 Cyrille None 4096 Jun 18  2010 exploitation
drwxrwsr-x+ 1 Cyrille None    0 Oct 12  2006 test

Cyrille AT nowhere ~/somewhere/cvs
v2$ for i in 1 2 3 4 5 6 7 8 9 0; do for j in 1 2 3 4 5 6 7 8 9 0; do
echo $i$j; done; done | xargs mkdir

Cyrille AT nowhere ~/somewhere/cvs
v2$ ls -ld
drwxrwsr-x+ 1 Cyrille None 16384 Jan  8 15:02 .

Cyrille AT nowhere ~/somewhere/cvs
v2$ for i in 1 2 3 4 5 6 7 8 9 0; do for j in 1 2 3 4 5 6 7 8 9 0; do
echo $i$j; done; done | xargs rmdir

Cyrille AT nowhere ~/somewhere/cvs
v2$ ls -ld
drwxrwsr-x+ 1 Cyrille None 16384 Jan  8 15:03 .

reboot

Cyrille AT nowhere ~/somewhere/cvs
$ ls -ld
drwxrwsr-x+ 1 Cyrille None 0 Jan  8 15:03 .

Cyrille AT nowhere ~/somewhere/cvs
$ find . > /dev/null

Cyrille AT nowhere ~/somewhere/cvs
$ ls -ld
drwxrwsr-x+ 1 Cyrille None 16384 Jan  8 15:03 .

IMHO, the first time the directory size is read, the size used by
FindFirstFile/FindNextFile (or something like that :-) is zero'ed,
then the directory size is updated while the directory is traversed.
also the directory size doesn't seem to shrink on entry removal,
even after a reboot.

Regards,

Cyrille Lefevre
--=20
mailto:Cyrille DOT Lefevre-lists AT laposte DOT net




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

- Raw text -