Re: symbolic link management in git-archive

From: Sergio Callegari <sergio.callegari@gmail.com>
Date: Mar 27, 2008, 12:11 UTC
Message-ID: <loom.20080327T115110-82@post.gmane.org>
In-Reply-To: <alpine.LSU.1.00.0803271244420.3802@racer.site>

Johannes Schindelin <Johannes.Schindelin <at> gmx.de> writes:

Show 6 quoted lines

> 
> Hi,
> 
> On Thu, 27 Mar 2008, Miklos Vajna wrote:
> 
> > On Thu, Mar 27, 2008 at 11:29:28AM +0000, Sergio Callegari <sergio.callegari

<at> gmail.com> wrote:

Show 12 quoted lines

> > > I guess the answer is "no" or "not yet", but is there a way to tell the zip
> > > backend of git-archive to follow symbolic links rather than to store them?
> > 
> > how would that handle a '. -> foo' symlink? following such a recursion
> > would lead to an infinite loop, i guess.
> 
> Don't forget '/ -> foo'.
> 
> Ciao,
> Dscho
> 
>

My question was inspired by the fact that the unix version of the zip program
has a switch, precisely to decide whether to follow or to store links.
I believe that the reason why this switch exist is clear: for some mysterious
reason the world is populated by OSs that do not understand symlinks and while
someone finds out why it is sensible to have workarounds. Obviously zip archives
with stored links are completely useless on these OSs.
BTW, note that also tar has a similar switch.
 
I believe that cases like the foo -> . or the foo -> /  (or even foo -> ..) can
be solved by either:

- limiting the symlink dereferentiation only to symlinks pointing to plain files

or

- leaving it to the user not to ask for link following when he knows that he has
such types of links

Personally I prefer the second. In the end:
- If these types of link exist, it is clear that the git-managed-stuff is not
made for certain OSs, so the user should know that asking for link following
makes no sense
- The user should know that there are some commands that might be dangerous
(think rm -fr ~), just warn them in the manual.
- The maximum risk here is to have the command never stop and fill the disk.

Sergio