X-Recipient: archive-cygwin AT delorie DOT com
X-Spam-Check-By: sourceware.org
Date: Tue, 26 Apr 2011 17:53:46 +0200
From: Corinna Vinschen <corinna-cygwin AT cygwin DOT com>
To: cygwin AT cygwin DOT com
Subject: Re: untarring symlinks with ../ fails randomly
Message-ID: <20110426155346.GA19578@calimero.vinschen.de>
Reply-To: cygwin AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com
References: <BANLkTikh9rCN2GRwY3eW20H0isffN5fMUg AT mail DOT gmail DOT com> <BANLkTi=GZbtLmK-Sr06-M=5xXVFzPCi82w AT mail DOT gmail DOT com> <20110424121145 DOT GB30696 AT calimero DOT vinschen DOT de> <loom DOT 20110425T165316-628 AT post DOT gmane DOT org> <20110426074325 DOT GP3324 AT calimero DOT vinschen DOT de> <loom DOT 20110426T170653-639 AT post DOT gmane DOT org> <20110426152226 DOT GA22801 AT ednor DOT casa DOT cgf DOT 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 AT cygwin DOT com; run by ezmlm
Precedence: bulk
List-Id: <cygwin.cygwin.com>
List-Unsubscribe: <mailto:cygwin-unsubscribe-archive-cygwin=delorie DOT com AT cygwin DOT 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 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