Re: gzip.exe as symlink breaks NTEmacs's jka-compr.el

[Jon Cast <jcast@ou.edu>]

Randall R Schulz <rrschulz@cris.com> wrote:
> Jon,
<snip>
> >I *think* I follow.  Of course, on Unix, symlinks /are/ aliases, so
> >the problem doesn't arise.

> No. Symlinks are indirections or pointers. The symlink is a distinct
> kind of file system entity and is always distinguishable from the
> original. With hard links each one is completely co-equal with the
> others and there's no such thing as the "real" file vs. the
> link. The latter is what I mean by "alias." This distinction between
> symlinks and hard links is equally applicable to Unix as it is to
> Cygwin, even though Cygwin symlinks are (nowadays) built upon
> Windows shortcuts.

This seems to be an issue of semantics: what does ``alias'' mean (see
below).

> The reason the problem doesn't occur on Linux, Unix or AIX (etc.) is
> that there is no environment or context in which an exec of a
> symlink fails (assuming, that is, that the symlink's target exists
> and is really executable). This is not true under Windows, where
> Windows itself will not follow a shortcut when carrying out it's
> equivalent of the "exec" system call.

Right.  On Unix, all of the system calls that succeed on a regular
(hard-linked) file succeed on a symlink and de-reference it.  So,
programs that aren't looking for symlinks won't notice them.  Not
technically an alias, but close enough.  Of course, on Windows major
system calls (CreateFile, CreateProcess, etc.) don't de-reference
Cygwin symlinks.  So, they're as good pseudo-aliases on Cygwin as on
Unix, but not on Windows.

<snip>
> >Actually, there is an (amortized) smaller way than copying the
> >files.  If the following program is compiled under Cygwin:

> >#include <unistd.h>

> >int
> >main (int argc, char **argv)
> >{
> >         execv ("/bin/gzip", argv);
> >}

> >It should do the same job as a symlink to /bin/gzip under both
> >Cygwin and Windows.  It's slightly less time-and-process efficient,
> >but if space is a concern it's probably better.  I don't have easy
> >access to a Cygwin box just at the moment, but on GNU/Linux (Redhat
> >7.3, to be precise) it's < 3k stripped.  A lot more than a symlink
> >(although I think Windows' filesystem granularity is higher than
> >that anyway), but less than just about any of the programs you
> >list.

> That is a viable alternative, and it is compact and universal, but
> it would make Cygwin building or packaging even more of a horse of a
> different color than it it already is.

Right.  I think you could argue supporting CreateProcess is the same
sort of job as supporting text mounts: tedious but worth-while.

> There's a directly analogous shell script that does essentially the
> same thing, too:

> -==--==--==--==--==-
> #!/bin/sh
>
> exec /bin/gzip "$@"
> -==--==--==--==--==-

It's not ``essentially'' the same thing.  First, it's incorrect, even
on Cygwin.  The reason for symlinking gzip (at least) is so that gzip
will check argv[0], find out it's "gunzip", and de-compress by
default.  So any symlink replacement needs to pass "gunzip" or some
such as argv[0].  The correct way to do this in shell is:

#! /bin/sh

exec -a "$0" /bin/gzip "$@"

However, it won't solve the problem at hand, which is supporting
CreateProcess: I don't think CreateProcess understand #!s :)

> > > I know that if one just uses the "ln" command (no "-s" option)
> > > on a FAT volume you get a copy. If Cygwin packages used hard
> > > links for program aliases (does the TAR format support hard
> > > links?)

> >Yes.

> > > and Setup.exe was given the same smarts as the "ln" command,
> > > you'd get space-wasting copies on FAT volumes and fast,
> > > space-efficient hard links on NTFS.

> >This is a good idea if space on FAT volumes is not a concern.

> Well, we used to regularly see complaints on the list about
> excessive disk consumption when the default install was all
> packages. Now that it's not, those complaints have been replaced
> with complaints of packages or programs being missing (when in fact
> the "missing" packages or programs simply were not installed).

You can't satisfy everyone on a list like this, especially when half
the posters seem to think they've a right to be satisfied :) By ``a
concern'' I meant ``the Cygwin maintainers care about this''.

> >Jon Cast

> Randall Schulz

Jon Cast

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Bug reporting:         http://cygwin.com/bugs.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/