This is the mail archive of the cygwin@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: 1.1.7:mount and ls problem


At 01:46 PM 1/24/2001, Earnie Boyd wrote:
>"Larry Hall (RFK Partners, Inc)" wrote:
> > 
> > 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.
> > 
>
>There is no way that I know of to prevent the user from removing the
>directory even if mounted.  The user could still use the Windows File
>Explorer or a cmd/command window to remove the directory.  To make it
>more difficult I suppose that the mount point directory could be marked
>with the system attribute when mounted and remove the system attribute
>when unmounted.  However, this still wouldn't prevent it's removal. 
>What I would suggest for this is that if the physical mount point
>directory is removed Cygwin recognizes this and removes the mount entry.


My point was the reverse.  On UNIX/Linux, its possible to unmount a 
directory, delete the directory, and then attempt to remount it.  It 
will error.  Still, your point is a good one.  There is an asymmetry
on Windows since there is nothing that prevents the user from removing
any mounted directory by other means (this you cannot do on UNIX/Linux).  
There may be a way to lock the directory to prevent this or do as you 
suggest (or some other scheme) but I certainly accept that the UNIX/Linux 
mount symantics in this respect don't come for free in Windows/Cygwin 
environments.  Addressing this whole issue is a nice little project.:-)


>What ever the solution is, the incorrect solution is to create the
>supposed physical directory.  Recently, I've been creating a /cygmnt
>directory at the root of each of my drive letters.  I then create mount
>points under the /cygmnt.  So if I want to have a mount point foo on
>drive D: then I would   mkdir D:/cygmnt/foo
>   mount -b D:/cygmnt/foo /foo
>The reason I do this is for ease of recognition of what I have mounted
>on what devices.


Right.  Automatic creation of the directory, IMO, is worse than the 
current behavior.  I don't really like the idea although someone may be
able to convince me of at least a specific case where it makes sense.


> > 
> > >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.
> > 
>
>IIRC, the decision for the warning was because it didn't use to warn or
>error and it was desired not to make it any more difficult.  I don't
>remember if Geoff Noer had intentioned it remaining a warning.  This
>goes back to 1998 if anyone cares to search the archives.



I doubt it!;-)



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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]