This is the mail archive of the cygwin-developers mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

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
>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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]