This is the mail archive of the
mailing list for the Cygwin project.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
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
>> /etc/fstab - Yes and get rid of the registry entirely
>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
>> >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.