delorie.com/archives/browse.cgi   search  
Mail Archives: cygwin-developers/1998/09/24/18:49:09

From: noer AT cygnus DOT com (Geoffrey Noer)
Subject: Update/more questions on mount points
24 Sep 1998 18:49:09 -0700 :
Message-ID: <19980924183652.58449.cygnus.cygwin32.developers@cygnus.com>
Mime-Version: 1.0
To: cygwin32-developers AT cygnus DOT com

Hi cygwin32-developers,

I'm paying more attention to mount table issues and I'd like a
little more feedback.  (This comes from some discussion that some of us
at Cygnus had earlier today).

Despite the fact that in some ways we'd like to require mount point
directories to exist (and most of you thought this was a good idea),
once they're there there's no easy enforcement Cygwin can do to
prevent a user from removing them.  In addition, the existance of
mount point directories is more of a convenience than a necessity.  So
it sounds like the best action to take is to modify the mount utility
so that it will print a warning message when a user attempts to mount
to a non-existing mount point directory.  (In fact, I've already
implemented this bit but if there are loud objections, I'd like to
hear them now).  :-)

A couple of possible additions:

1) Should mount ask the user whether they want the directory created
   for them?  (Tempted to just print a warning and keep mount
   non-interactive).

2) Should mount have a flag that would make it scan the mount
   tables and create all missing mount-point directories?

FYI, I am extending mount to handle the choice of user vs. global
mount tables.  Fortunately, that seems to be pretty straight-forward
unlike most of the rest of this.

I still think that the //<drive-letter> hack should die.
We seem to basically be in agreement with this.  But the trouble with
removing it is how it affects path translations from Win32 to POSIX.
Currently, Cygwin uses the //<drive-letter> hack to create a valid
POSIX path when it can't use mount points.  We would need to come up
with a good workaround.

I'm currently thinking that we should detect the inability to
translate a particular path from Win32 to POSIX.  Cygwin would then
create a mount point on the fly for the drive letter in question.  So
Q: would be added to the HKEY_LOCAL_USER mount table as /q or /mnt/q
(whichever makes more sense) and then that mount point would be used
for that and future translations involving that drive letter.  Of
course, the user could always opt to remove it and put in a different
mapping later if they so choose.

The reason to do it in HKEY_LOCAL_USER is that different users would
have different network drive mount points.  That makes sense to me as
enough of a reason to do it there.  And since it would stick around,
there wouldn't have to be any magical handling of /mnt in the path
code which would keep things simple.

A final issue is that non of us here particularly like the way that
the DLL auto-creates mount points on loading, especially for the four
raw devices fd0, fd1, st0, st1.  Instead, we are thinking that perhaps
this should be done at install time.  Or the user should add them
themselves.  With these gone, the only purpose of mount_init is to
verify that there's a slash mount.  I don't suppose there's a way we
could go without this too?  (And have Cygwin create the default slash
mount when it is first requested, similarly to how new drive letters
would be handled as described above?).

Thoughts?

Geoffrey Noer
noer AT cygnus DOT com

- Raw text -


  webmaster     delorie software   privacy  
  Copyright © 2019   by DJ Delorie     Updated Jul 2019