X-Recipient:	archive-cygwin AT delorie DOT com
X-SWARE-Spam-Status:	No, hits=0.7 required=5.0 tests=AWL,BAYES_50,SPF_NEUTRAL,TO_NO_BRKTS_PCNT
X-Spam-Check-By:	sourceware.org
Message-ID:	<4E1301BC.3090809@cs.utoronto.ca>
Date:	Tue, 05 Jul 2011 08:21:16 -0400
From:	Ryan Johnson <ryan DOT johnson AT cs DOT utoronto DOT ca>
User-Agent:	Mozilla/5.0 (Windows; U; Windows NT 6.1; en-US; rv:1.9.2.18) Gecko/20110616 Lightning/1.0b2 Thunderbird/3.1.11
MIME-Version:	1.0
To:	cygwin AT cygwin DOT com
Subject:	Re: untarring symlinks with ../ fails randomly, silghtly OT
References:	<1309437783 DOT 2097 DOT 68 DOT camel AT geldmacher-pc> <20110630133703 DOT GE9552 AT calimero DOT vinschen DOT de> <4E0C90B2 DOT 2060409 AT cornell DOT edu> <1309447688 DOT 12904 DOT 21 DOT camel AT geldmacher-pc> <1309770955 DOT 22699 DOT 15 DOT camel AT geldmacher-pc> <20110704104656 DOT GA20822 AT calimero DOT vinschen DOT de> <20110705121059 DOT GI1457 AT calimero DOT vinschen DOT de>
In-Reply-To:	<20110705121059.GI1457@calimero.vinschen.de>
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

On 05/07/2011 8:10 AM, Corinna Vinschen wrote:
> On Jul  4 12:46, Corinna Vinschen wrote:
>> On Jul  4 11:15, Wolf Geldmacher wrote:
>>> As an aside:
>>> 	I also used to have some trouble with "rm -rf" of a directory
>>> 	hierarchy failing more or less reproducibly (like: 80% of the
>>> 	time) because files were presumably still "in use". Repeating
>>> 	the command several times would succeed, though.
>>>
>>> 	Downgrading from cygwin1.dll/1.7.9.1 to cygwin1.dll/1.7.8.1
>>> 	seems to have solved that issue as well - still have to see
>>> 	the first "retry to delete".
>>>
>>> This may or may not be related to the original report, as it also reeks
>>> of a race condition during file/directory operations.
>> I can neither reproduce the tar problem, nor can I reprocude the rm
>> problem.  I tried this under 2008R2 which is basically the same as your
>> W7-64 bit.  I used local and remote drives to test the issue but to no
>> avail.
> Finally I managed to reproduce the problem and now I see what happens.
>
> Windows does not write back the file change timestamp unless the file
> buffers are flushed.  This usually occurs at close time.  In contrast to
> POSIX specifications the timestamps are *not* automatically updated when
> a call to fetch file metadata is performed.
>
> Here's what tar does when creating the symlink:
>
>    1. create file with 000 permissions
>    2. fstat
>    3. close file
>    [...]
>    4. stat file
>    5. if fstat.st_ctime != stat.st_ctime ==>  symlink placeholder has been
>       overwritten.
>
> The problem is that the call to fstat on the opened handle gets some
> value of the change time timestamp, but the subsequent close changes
> the timestamp again.
Wow. That must have been one hairy debug session... my hat goes off to you!

Ryan


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