Mailing-List: contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
List-Subscribe: <mailto:cygwin-subscribe AT sources DOT redhat DOT com>
List-Archive: <http://sources.redhat.com/ml/cygwin/>
List-Post: <mailto:cygwin AT sources DOT redhat DOT com>
List-Help: <mailto:cygwin-help AT sources DOT redhat DOT com>, <http://sources.redhat.com/ml/#faqs>
Sender: cygwin-owner AT sources DOT redhat DOT com
Delivered-To: mailing list cygwin AT sources DOT redhat DOT com
Message-Id: <4.3.1.2.20010227124529.01765318@pop.ma.ultranet.com>
X-Sender: lhall AT pop DOT ma DOT ultranet DOT com
X-Mailer: QUALCOMM Windows Eudora Version 4.3.1
Date: Tue, 27 Feb 2001 12:51:18 -0500
To: cygwin AT cygwin DOT com
From: "Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
Subject: Re: New symlinks.
In-Reply-To: <20010227114332.F10689@redhat.com>
References: <20010227171730 DOT L4275 AT cygbert DOT vinschen DOT de>
 <20010227064205 DOT 24363 DOT qmail AT web6404 DOT mail DOT yahoo DOT com>
 <20010227104026 DOT B10525 AT redhat DOT com>
 <20010227171730 DOT L4275 AT cygbert DOT vinschen DOT de>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:43 AM 2/27/2001, Christopher Faylor wrote:
> >> I am, as always, more concerned about supporting this feature in
> >> the long run.  If allowing foo.lnk to be referenced explicitly causes
> >> even one person confusion, I don't think that it is worth it.  It
> >> is certainly non-UNIX behavior.
> >
> >I think it's correct behaviour. Cygwin doesn't show the .lnk
> >suffix by itself but nevertheless, to return a `file not found'
> >on `ls foo.lnk' wouldn't be correct. It's simply the truth:
> >The file `foo.lnk' exists and is a symlink.
>
>Again, it is surprising behavior.  Such a file would not exist on UNIX.
>I personally think that we should hide implementation details like
>"Oh yeah, we added a .lnk extension to all of our symbolic links"
>from the user.  There is no reason for them to know or care about
>this detail.


Certainly Windows tries to take this tack, although I loathe to point to 
them as an indication of what should be done.  Personally, I've never 
liked the notion of a file type being indicated by its extension though
so I'm always for something that removes this dependencies or makes it
transparent.  Still, I'm pontificating, since I haven't looked at the code
or tried to see how/if this could be done in the context of Windows 
shortcuts.  Overall, while I like the inter-operability gains, bring 
Windows semantics into UNIXy symbolic links will be a problem.





--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple