On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: >On Apr 3 09:56, Christopher Faylor wrote: >> On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: >> > - Do we drop registry mount points and store mount points in future >> > in fstab-like files as, say, /etc/fstab (system mount points) and >> > ~/.fstab (user mount points)? >> > >> >Having said that... >> >> FWIW: ~/.fstab - No > >I don't think that's as easily implementable as having such a file >in /etc anyway, but you're making an important note below, so, see >there. > >> /etc/fstab - Yes and get rid of the registry entirely > >ACK. > >The reason I implemented this with using the registry as a fallback >is for easier testing. The idea is that we (developers and maintainers) >can start to use the fstab approach, while normal users on the Cygwin >list, who are just curious, still can run a snapshot in their otherwise >unchanged environment. > >> >On Apr 2 17:56, Charles Wilson wrote: >> >> Corinna Vinschen wrote: >> >>> Get own path ==> C:\\cygwin\\bin\\cygwin1.dll >> >>> Where's fstab? ==> C:\\cygwin\\etc\\fstab >> >> >> >> So, it implicitly computes where / is? >> > >> >No, it doesn't. It just snips away the last two path components and >> >tacks the etc/fstab string on. Plus the .$SID to get the user mounts. >> > >> >After the mount points have been read, root can potentially be >> >somewhere else entirely. >> >> I think that's the right way to handle this. > >That puzzles me a bit, because of what you write below. > >> >>> these are my fstab files: >> >>> $ cat /etc/fstab >> >>> C:\cygwin / ntfs binary 0 0 >> >> >> >> Which means that the line above really ought to match the computed '/', >> >> or >> >> bad things might happen, right? If so, then it is redundant to specify it >> >> here. Perhaps this should just be autocomputed...since the fstype and >> >> last >> >> two elements are ignored. >> > >> >Yes, I thought about this, too. It doesn't really seem to make much >> >sense to redefine /. As for /usr/bin and /usr/lib, these paths are >> >not inherently defined by the DLL. They exist because a decision >> >has been made how to create a Cygwin installation in the net distro. >> >This could be changed in future, or our internal Red Hat release >> >could need another layout. There's no reason to couple this distro >> >decision to the DLL, IMHO. >> >> For 1.7, I think we ought to decouple /bin <> /usr/bin and /lib <> >> /usr/lib. The rationale for keeping those linked no longer applies in >> the modern setup.exe world. > >Full ACK! However, this needs a bit of careful revisiting of some of >the packages. For instance, assuming the Cygwin DLL will go to /bin, >cygrunsrv should also reside in /bin when we do this, not in /usr/bin, >obviously. Right now I must admit that I prectically don't care if my >packages install the binaries in /bin or /usr/bin. > >> >Or simply >> > >> > root / ntfs binary 0 0 >> > >> >and stick to /usr/bin and /usr/lib as they are today. >> >> I think something like an automount is needed since it would be nice to >> eventually generalize the cygdrive stuff and we don't want to explicitly >> mount a: - z: So, maybe we could consider a linux-like solution to >> accomplish this although I really don't like automount. > >I'm not sure I understand this, that's why I was puzzled above. >Do you think that / should be free as today: > > C:\arbitrary\useless\new\path / ntfs binary 0 0 > >or do you think an automatic approach as the above > > root / ntfs binary 0 0 > >is the way to go? As for cygdrives, isn't the > > cygdrive /mnt auto binary 0 0 > >already along the lines of an automount?!?
"auto" in /etc/fstab doesn't mean "automount". It means that it is meant to be "auto"matically mounted at "boot time". That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. >> >Another problem is that the 1.7 mount(1) still creates the mount entries >> >in the registry. This should be removed, if we stick to the file based >> >approach. mount would only create temporary mount points which are >> >only valid in this single session, until the last Cygwin process in this >> >session exits. A bit like a reboot on Linux :) >> >> On XP it should be possible to make it so that the mounts last until >> reboot. If we can do that I think it would be ideal. > >How? The mount points are bound to the existance of the shared >memory they reside in. This shared mem disappears when the last >Cygwin process in a session exits. I have to research what I'm thinking of but I think it's possible. I don't know if it is possible for a non-privileged user though. cgf
