Mailing-List: contact cygwin-developers-help AT cygwin DOT com; run by ezmlm List-Subscribe: List-Archive: List-Post: List-Help: , Sender: cygwin-developers-owner AT cygwin DOT com Delivered-To: mailing list cygwin-developers AT cygwin DOT com Message-ID: <3D78A504.67C2206E@yahoo.com> Date: Fri, 06 Sep 2002 08:52:20 -0400 From: Earnie Boyd Reply-To: cygwin-developers AT cygwin DOT com X-Accept-Language: en MIME-Version: 1.0 To: cygwin-developers AT cygwin DOT com Subject: Re: Contemplating drastic change to mount handling References: <20020906030958 DOT GA27496 AT redhat DOT com> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit Christopher Faylor wrote: > > I'm thinking of making a drastic change to mount handling. > > Basically, I'd like to eliminate most of the registry and move mount > handling into two files: /etc/fstab and /etc/mtab. > Seems familiar. I seem to remember discussing this with you in the previous century. > /etc/fstab would be the same as it is on linux. /etc/mtab would be a > binary (trie) representation of the mount table which could be mapped > into cygwin on the fly, eliminating the need to parse any options. > I need educated on "trie". Do you mean tree or is it something else? > We'd still use the registry as a method for finding /etc but that would > be it. > You could take the approach I did for MSYS and base the root / mount point on the parent of the directory containing the cygwin1.dll. It eliminates the need for the registry entry. The /bin mount point is the directory containing the cygwin1.dll. Both / and /bin and noumount. And while you're at it, /bin should be cygexec. With MSYS I also made /usr equivalent to / but that could be debatable for Cygwin and don't have preconceived advice for it's usefulness for Cygwin. > In this scheme, /etc/mtab would be different than it usually is on unix, > so maybe it should actually be called something like /etc/bmtab. It > would be manipulated only by mount. > Well, you could instead use /proc/mtab. This protects it from being modified by some outside source. -8<- > I'd also like to get rid of the cygwin method of doing things where if > you type "mount c:\foo /foo" then the mount is permanent. I'd like to > make the mount only exist until the next umount or reboot, like UNIX. > That doesn't necessarily fall out of this scheme but I have a half > formed idea of how to handle this, too. > > So, basically the "permanent" mounts would be whatever existed in > /etc/fstab, maybe with an auto field turned on. > Yep. Sounds good. > I don't have this fully fleshed out in my mind yet but I thought I'd > type out my thoughts here. This will undoubtedly cause a lot of > confusion since it is a drastic change. I would feel a little uneasy > about making 'mount' impermanent but changing the registry keys doesn't > bother me at all. I've been telling people not to directly manipulate > the registry for years. > Changes are always interesting. There will always be the extraneous existing documentation, especially those not controlled by Cygwin that will cause much grief. > Oh, and the other thing that would be nice to come out of all this would > be a generic library that could be linked into other applications (like > cygcheck and setup) which could manipulate the mount table. > That obviously would be good, would it be mtab it reads or fstab? You haven't mentioned though the /cygdrive implementation. For MSYS I removed the /cygdrive and added automounts for each drive letter. > Obviously not something for 1.3.13... > Yea, more like something for 2.0.0 even though the ABI is still backward compatible. If the ABI remains backward compatible then `cp cygwin2.dll cygwin1.dll' on installation allows existing cygwin1.dll dependent binaries to continue to operate. Earnie.