Mailing-List:	contact cygwin-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender:	cygwin-owner AT sourceware DOT cygnus DOT com
Delivered-To:	mailing list cygwin AT sourceware DOT cygnus DOT com
Message-Id:	<3.0.5.32.19990329192524.00a1b9b0@pop.ma.ultranet.com>
X-Sender:	lhall AT pop DOT ma DOT ultranet DOT com
X-Mailer:	QUALCOMM Windows Eudora Pro Version 3.0.5 (32)
Date:	Mon, 29 Mar 1999 19:25:24 -0500
To:	Corinna Vinschen <corinna DOT vinschen AT cityweb DOT de>
From:	"Larry Hall (RFK Partners, Inc)" <lhall AT rfk DOT com>
Subject:	Re: B20: mv deletes files on error (NT)
Cc:	earnie_boyd AT yahoo DOT com, cygwin users <cygwin AT sourceware DOT cygnus DOT com>
In-Reply-To:	<3700189E.A832DFB0@cityweb.de>
References:	<3 DOT 0 DOT 5 DOT 32 DOT 19990329184811 DOT 00a1d360 AT pop DOT ma DOT ultranet DOT com>
Mime-Version:	1.0

At 02:19 AM 3/30/99 +0200, Corinna Vinschen wrote:
>
>
>"Larry Hall (RFK Partners, Inc)" wrote:
>> 
>> Well, let's flip the question.  Why is it not adequate to modify "ln" to
>> handle the issue of hard links?  This is not without precedent since it had
>> to be done at one time for file systems that don't support hard links (like
>> FAT).
>> 
>> Whether or not foo and Foo are the same file, I see no reason why one can't
>> rename it in a case-sensitive manner.  I can in the Explorer.  I can using
>> DOS commands (like MOVE).  Why shouldn't I be able to keep doing this in
>> Cygwin?  Why does the change to support hard links necessitate a change in
>> Cygwin where support for "mv" does not?  Mind you, I'm not arguing that
>> the support for hard links is bad but merely that the change made to support
>> them may not be the best approach to getting them!  Is there anyone who can
>> clarify that point?  The rest is just opinion, which while great for
>> discussion, usually wears thin after a time.
>
>Sorry, but I don't understand your intention.
>
>- cygwin has supported hard links earlier already.
>- `ln' supported hard links earlier, too.
>- The change, I made, didn't invent hard link support, but the ability,
>  to recognize them. It uses the type of i-node number, which is generated
>  by windows itself. Moreover the filename hashing method was never correctly
>  implemented, because it was case sensitive, which did never reflect the
>  file system behaviour.
>- Shouldn't be the behaviour of mv corrected, instead of working incorrect
>  in an inner part of the system? Wouldn't this be a more future oriented
>  solution?
>  BTW: `mv' did never work correctly on files which ends up in `.exe'. Try:
>	mv foo foo.exe    <-- this works
>	mv foo.exe foo    <-- this not:
>	`mv: `ln.exe' and `ln' are the same file'
>- As mentioned by Earnie: Changing `mv' is really simple (a type of a one liner).
>
>- In the meantime, try `mv foo bar; mv bar Foo'. ;)
>
>Regards,
>Corinna
>

Let me make my final points:

1. I guess I don't understand why you threw the issue of hard links into the
    discussion if your change had nothing to do with them really, which was 
    the root of what I was trying to get at. 

2. Your comment about how mv works with "mv foo.exe foo" is not quite on
   target.  I agree that this is not correct functionality.  However, it
   was added quite a while ago simply because people wanted it.

3. If everyone agrees that the best thing to do is modify "mv" and this is
   the only change necessary to make sure "mv" doesn't break as a result,
   how come its not part of the change?  Shouldn't the goal be to improve
   Cygwin rather than taking one step forward and then one step back? 


Larry Hall                             lhall AT rfk DOT com
RFK Partners, Inc.                     (781) 239-1053
8 Grove Street                         (781) 239-1655
Wellesley, MA, 02482-7797              http://www.rfk.com

--
Want to unsubscribe from this list?
Send a message to cygwin-unsubscribe AT sourceware DOT cygnus DOT com

- Raw text -