X-Recipient: archive-cygwin AT delorie DOT com X-SWARE-Spam-Status: No, hits=-1.2 required=5.0 tests=AWL,BAYES_00,T_RP_MATCHES_RCVD X-Spam-Check-By: sourceware.org Subject: Re: untarring symlinks with ../ fails randomly, silghtly OT From: Wolf Geldmacher To: cygwin AT cygwin DOT com In-Reply-To: <4E1301BC.3090809@cs.utoronto.ca> 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> <4E1301BC DOT 3090809 AT cs DOT utoronto DOT ca> Content-Type: text/plain; charset="UTF-8" Date: Tue, 05 Jul 2011 19:01:41 +0200 Message-ID: <1309885301.331.1.camel@geldmacher-pc> Mime-Version: 1.0 Content-Transfer-Encoding: 7bit X-IsSubscribed: yes Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: 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 Tue, 2011-07-05 at 08:21 -0400, Ryan Johnson wrote: > 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 Definitely agree! (Where's the "Like" button?) -- 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