From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Larry Hall (RFK Partners, Inc)" To: cygwin@sources.redhat.com Cc: ehud@unix.simonwiesel.co.il, lowella@serv.net, cygwin@sources.redhat.com Subject: Re: 1.1.7:mount and ls problem Date: Wed, 24 Jan 2001 11:17:00 -0000 Message-id: <4.3.1.2.20010124140328.02259dd0@pop.ma.ultranet.com> 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.20010124121519.0228be88@pop.ma.ultranet.com> <3A6F2317.686CD2BD@yahoo.com> X-SW-Source: 2001-01/msg01216.html 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