Mailing-List: contact cygwin-help@sourceware.cygnus.com; run by ezmlm
Sender: cygwin-owner@sources.redhat.com
Message-Id: <4.3.1.2.20010124121519.0228be88@pop.ma.ultranet.com>
Date: Wed, 24 Jan 2001 12:21:42 -0500
To: ehud@unix.simonwiesel.co.il
From: "Larry Hall (RFK Partners, Inc)" <lhall@rfk.com>
Subject: Re: 1.1.7:mount and ls problem
Cc: lowella@serv.net, cygwin@sources.redhat.com
In-Reply-To: <200101241656.SAA04669@linux.>
References: <4.3.1.2.20010124100612.021e0c10@pop.ma.ultranet.com>
 <4.3.1.2.20010123202852.022d7ce8@pop.ma.ultranet.com>
 <4.3.1.2.20010124100612.021e0c10@pop.ma.ultranet.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"

At 11:56 AM 1/24/2001, Ehud Karni wrote:
> >          cd /
> >          mkdir e
> >          mount e: /e
> > All is well -- e shows up in both an ls ( as e) and mount (as e:  /e).
> > 
> >          mount f: /f
> > I get the error:
> >          mount: warning - /f does not exist
> > but mount shows
> >          f:   f/ . . .
> > and ls doesn't show f.
> > 
> > If I do mkdir f, I get:
> >          mkdir: cannot make directory `f': File exists
>  
>On UNIX systems, you can NOT mount on non-existing directory.
>
>I think Cygwin can adopt this behavior and refuse to mount when the
>directory is missing. There are 2 ways to accomplish this:
>     1. Create the directory (silently or with a message).
>     2. Produce an  error and do not mount.
>The 2nd approach has the possible problem for mounts that was done
>previously (saved in the registry) - the mount directory may be erased
>by a non Cygwin program. In that case I will produce an error message
>every time the DLL try to use this mount, and ignore it (but not
>delete it from the registry).


This may be an issue.  The simple approach for handling this here would
be do 1, although one could always see what UNIX/Linux does in these cases
too.  As I recall, UNIX/Linux simply displays an error if the directory to
mount to is removed.  I see no real problem with supporting this approach
either.
  

>I don't know the reasons of the Cygwin developers for choosing the
>current behavior but I'm sure they had something in mind if they
>decided to deviate from standard UNIX practice.


Yes, I'm sure there was a reason.  It may have just been for "expediency".
In any case, its not worth speculating unless someone plans to take up the
task.


Larry Hall                              lhall@rfk.com
RFK Partners, Inc.                      http://www.rfk.com
118 Washington Street                   (508) 893-9779 - RFK Office
Holliston, MA 01746                     (508) 893-9889 - FAX


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