This is the mail archive of the
mailing list for the Cygwin project.
Re: gzip.exe as symlink breaks NTEmacs's jka-compr.el
- From: Randall R Schulz <rrschulz at cris dot com>
- To: Jon Cast <jcast at ou dot edu>
- Cc: cygwin at cygwin dot com
- Date: Tue, 16 Jul 2002 20:15:12 -0700
- Subject: Re: gzip.exe as symlink breaks NTEmacs's jka-compr.el
- References: <Message from Randall R Schulz <firstname.lastname@example.org><email@example.com>
At 19:44 2002-07-16, Jon Cast wrote:
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.
Randall R Schulz <firstname.lastname@example.org> wrote:
> 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.
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.
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.
> 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:
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.
There's a directly analogous shell script that does essentially the same
exec /bin/gzip "$@"
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
> 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.
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Bug reporting: http://cygwin.com/bugs.html