Subject: Shortcuts as symlinks (was: v18 vs v17 compile times....)
From: [email-masked] (Ken Keys)

25 May 1997 20:37:04 -0700
Approved: [email-masked]
Distribution: cygnus
Message-ID: <[email-masked]>
Mime-Version: 1.0
Content-Type: text/plain; charset=US-ASCII
Content-Transfer-Encoding: 7bit
Original-To: [email-masked] (Michael Condict)
Original-Cc: [email-masked]
In-Reply-To: <[email-masked]> from "Michael Condict" at May 23, 97 11:13:17 am
X-Mailer: ELM [version 2.4 PL24]
Original-Sender: [email-masked]

Michael Condict ([email-masked]) wrote:

> I'd like to step back and point out that Windows 95 / NT 4 already *have*
> symlinks.  They are ".lnk" files for folders, data files and Win32 programs,
> and ".pif" files for 16-bit programs.  They have all the power of UNIX
> symlinks in what information is stored in them, and more.
> 
> Now it's true that Windows makes very poor use of these symlinks,
> allowing them to have meaning only if you double-click on them in an
> Explorer window or feed them to the "Run" menu or the "start" command.
> You can't "cd" through them or print the contents of the file to which
> they point using the "type" command.  But this is no reason that Cygnus
> Win32 can't endow them with the full power of UNIX symlinks.  This would
> be a solution that does not require reading a symlink file.
> 
> It's also much better integrated with Windows.  Wouldn't it be nice if
> you could navigate through Cygnus Win32 symlinks using Explorer?  When
> you've made c:/bin be a symlink/shortcut to the Cygnus godawfully named
> ".../H-i386-cygwin32/bin" directory, wouldn't it be nice if you could
> type e.g. "/bin/bash" to the Start / Run window, and have it start up
> bash?
> 
> Here are some details of how such links could work:
> 
> 	1) Readdir, when returning the names of files in a directory,
> 	   should delete the suffix ".lnk" or ".pif", if present.
> 
> 	2) In the open syscall, if an attempt to open a file fails with
> 	   a "not found" error, open should suffix ".lnk" and try
> 	   again.  If that fails, it should suffix ".pif" and try
> 	   again.  If either of these succeeds, open should then read
> 	   the shortcut file, find the path name of the target, and do a
> 	   Win32 open of the target file.  This will slow down the
> 	   processing of sym links a bit (because a failed open has to
> 	   take place first), but allows non-symlink files to be
> 	   processed without any overhead added by the symlink code.
> 
> 	3) The other syscalls that take a pathname and are supposed to
> 	   follow symlinks (e.g. chdir, stat), should select the target
> 	   file or folder similarly to the algorithm used by open.

I agree, this would be very useful.  It's so obvious that I wonder why
it wasn't done in the first place.  The only reason I didn't propose it
myself several weeks ago is that I didn't know enough about how .lnk and
..pif files really worked.

There is one minor problem with your proposal: readdir can't just delete
the suffix, since the prefix may not be unique (e.g., files "foo" and
"foo.lnk" would both look like "foo").  The solution is simply to have
readdir() not remove the suffix.  This would parallel the way ".exe" and
".bat" files are already handled.

Having symlinks be shortcuts would also allow symlinks to executables to
work, instead of failing to find the dll as they do currently.  (I guess
the cygwin exec() would have to expand its search to include files
ending in ".lnk" and ".pif", but it wouldn't have to do anything
special with them, since the windows calls would take care of the rest.)

-- 
Ken Keys ([email-masked])
Software Engineering Team Leader
CommerceWave, Inc.
-
For help on using this list (especially unsubscribing), send a message to
"[email-masked]" with one line of text: "help".