Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
From: "Lothan" <lothan@newsguy.com>
To: <cygwin@cygwin.com>
Subject: RE: New symlinks.
Date: Tue, 27 Feb 2001 23:20:31 -0800
Message-ID: <GAENLJIGIGCHDHJMOLPDOEOCCFAA.lothan@newsguy.com>
MIME-Version: 1.0
Content-Type: text/plain;
	charset="us-ascii"
Content-Transfer-Encoding: 7bit
In-reply-To: <20010227114332.F10689@redhat.com>
Importance: Normal

> From: cygwin-owner@sources.redhat.com
> [mailto:cygwin-owner@sources.redhat.com]On Behalf Of Christopher Faylor
> Sent: Tuesday, February 27, 2001 8:44 AM
> To: Cygwin
> Subject: Re: New symlinks.
>
>
> >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.

Perhaps this is true, but it does lead to a much nicer surprise. Let's say I
have a link called ~/foo and some package (or me for that matter) wants to
create a file called foo.lnk? It's a surprise to say that foo.lnk already
exists since all I see is foo. It's a totally different surprise if foo
suddenly gets overwritten by foo.lnk.


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