This is the mail archive of the 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]
Other format: [Raw text]

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


At 19:44 2002-07-16, Jon Cast wrote:
Randall R Schulz <> 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.


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

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:


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


> 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:
Bug reporting:

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