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

[Randall R Schulz]

Jon,

At 19:44 2002-07-16, Jon Cast wrote:
>Randall R Schulz <rrschulz@cris.com> wrote:
> > Jon,
>
> > I think you're right.  There's a fundamental asymmetry created by
> > following the Unix convention of symlinks as aliases (in lieu of
> > universally applicable hard links, which are true aliases).
>
>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.

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.


> > Simply having Cygwin's /bin in your PATH makes it possible to run
> > Cygwin ".exe" files, but not Cygwin symlinks unless it's a Cygwin
> > program that attempts to invoke the alias.
>
>True.
>
> > I guess the best answer for addressing this asymmetry from the
> > standpoint of simplicity and universality is to simply copy the
> > binary separately to each named program that binary implements.
>
> > Unfortunately, some of those files are pretty big. Witness these
> > symlink targets from /bin (repeats reflect there being more than one
> > symlink targeting the same binary):
>
> >... [ long list of /bin symlink targets deleted ] ...
>
>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.

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

-==--==--==--==--==-
#!/bin/sh

exec /bin/gzip "$@"
-==--==--==--==--==-


> > 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).


>Jon Cast


Randall Schulz


--
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/