This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: [ANNOUNCEMENT]: Important change to symbolic linkfunctionali ty



----- Original Message -----
From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
To: "Earnie Boyd" <cygwin@cygwin.com>
Sent: Friday, February 23, 2001 8:34 AM
Subject: Re: [ANNOUNCEMENT]: Important change to symbolic
linkfunctionali ty


> At 04:30 PM 2/22/2001, Earnie Boyd wrote:
> >You misunderstand Corinna.  She is saying that the *.lnk files
wouldn't
> >be in the tarball only the attribute of the links and the *.lnk file
> >would be recreated when extracting it from the tarball.  The *.lnk
file
> >itself would not be extracted but recreated.
>
>
> Ah, OK.  I guess I don't know how the "attribute of the links" are
represented
> but if the symlinks are recreated, that should take care of the basic
problem.
> So these "attributes" would still be platform specific, just like the
current
> symlinks, right?
>
>
>
> Larry Hall                              lhall@rfk.com


Well symlinks _are platform specific_. You can't pick up the inode from
a 64 bit filesystem and drop it onto a logical sector of a ext2fs
filesystem and expect it to work. It just so happens that nearly every
unix filesystem has a symlink flag.

As I understand cygwin's tar's behaviour, it stores a file, with the
symlink bit set in that tarball, and the content the path to the new
file - just as gnu tar on linux does. then when it's extracted onto
whatever platform, tar requests a symlink, and the platform takes care
of creating a platform specific symlink.

Rob


--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]