This is the mail archive of the cygwin-apps 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 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?!?

> >I have the vague feeling it would be sufficient to install only a
> >/etc/fstab, even in "just me" mode, though.  The fstab.$SID file is
> >only necessary in multi-user installations, IMHO.
> 
> Why do we need a fstab.$SID and linux doesn't need this?

Let me think...

I don't know.  I assume I just took this as it is.  I guess the
only reason to create user mounts to begin with was, so that any
non-privileged user can create mount points, too, for a pure
"just me" installation in a restricted environment.

However, that's not really necessary anymore with /etc/fstab.
So I agree, we can simply get rid of fstab.$SID.

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


Corinna

-- 
Corinna Vinschen                  Please, send mails regarding Cygwin to
Cygwin Project Co-Leader          cygwin AT cygwin DOT com
Red Hat


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