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 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> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm List-Id: List-Subscribe: List-Archive: List-Post: List-Help: , 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