X-Recipient: archive-cygwin@delorie.com X-Spam-Check-By: sourceware.org Date: Tue, 26 Apr 2011 17:53:46 +0200 From: Corinna Vinschen To: cygwin@cygwin.com Subject: Re: untarring symlinks with ../ fails randomly Message-ID: <20110426155346.GA19578@calimero.vinschen.de> Reply-To: cygwin@cygwin.com Mail-Followup-To: cygwin@cygwin.com References: <20110424121145.GB30696@calimero.vinschen.de> <20110426074325.GP3324@calimero.vinschen.de> <20110426152226.GA22801@ednor.casa.cgf.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <20110426152226.GA22801@ednor.casa.cgf.cx> User-Agent: Mutt/1.5.21 (2010-09-15) Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm Precedence: bulk List-Id: List-Unsubscribe: List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-owner@cygwin.com Mail-Followup-To: cygwin@cygwin.com Delivered-To: mailing list cygwin@cygwin.com On Apr 26 11:22, Christopher Faylor wrote: > On Tue, Apr 26, 2011 at 03:08:52PM +0000, Dan Grayson wrote: > >(Re-posting yet again, didn't get through yesterday or today (?), this time > >from a different account.) > > > > > >Corinna, > > > >Debugging with gdb shows that "tar" is prepared for the possibility that > >symbolic links don't work and that hard links will have to be used instead. > >So, when it encounters a symbolic link, it creates a zero-length file with mode > >0 as a placeholder, and it records the inode number of the new file. That way > >it can wait until all the regular files have been created, and then replace the > >placeholder by a symbolic link, or if that doesn't work, by a hard link to the > >existing file. However, a tar file can contain multiple entries corresponding > >to the same file name or path, so it may happen that the placeholder is no > >longer present at the end, having been replaced by another file. Hence, it > >will only replace the placeholder if the inode number and the creation time are > >unchanged. But, under cygwin, the creation time may change gratuitously after > >the creation of the file, at random! > > Cygwin doesn't change the creation time gratuitously. Sounds like BLODA to me. Btw., POSIX st_ctime is not "creation time" but "change time". It's the timestamp of the last change to the file's metadata (inode content on filesystems like ext2/3/4). The "change time" was always available in file info calls in the native NT API, and it's available in the Win32 API since Windows Vista (see http://msdn.microsoft.com/en-us/library/aa364226%28v=VS.85%29.aspx) Unfortunately Microsoft doesn't provide documentation on the resolution of the "change time", only of the other timestamps, see http://msdn.microsoft.com/en-us/library/ms724290%28v=VS.85%29.aspx If you're looking for the creation time, it's in st_birthtime. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- 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