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>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
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