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 11:42:20AM +0200, Corinna Vinschen wrote:
>For a start, please note that this patch is just preliminary.
>The actual problem is still one of the problems I noted in my mail
>http://cygwin.com/ml/cygwin-developers/2008-03/msg00000.html, to which I
>didn't get a reply, except from Brian.
> - The POSIX path of mount points is restricted to 256 characters.
> That's because it's used as the value name of a registry value and
> value names are restricted to (surprise!) 256 chars. A decision
> and, perhaps, coding has to be done:
> - Do we stick to this restriction?
> - Do we introduce a new mount point storage in the registry?
> - 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
/etc/fstab - Yes and get rid of the registry entirely
>On Apr 2 17:56, Charles Wilson wrote:
>> Corinna Vinschen wrote:
>>> I have applied a preliminary patch to Cygwin which allows to load the
>>> mount entries from /etc/fstab and /etc/fstab.<usersid>. If none of
>>> these files is available, the DLL falls back to reading the mount points
>>> from the registry.
>> I like this. A lot.
>>> Cygwin finds the fstab files by fetching it's own Win32 path and then
>>> replacing the last two path components with etc/fstab or
>>> etc/fstab.<usersid>, like this:
>>> 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.
>>> The layout of the fstab file follows the Linux layout. As example,
>>> 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.
>> Maybe there should be "special" rules for the three special autocomputed
>> mount points:
>> # NOTE: the three "magic" auto-computed paths are present
>> # in this file strictly so that mount options may be specified.
>> C:\This\Path\Is\AutoComputed / ntfs binary 0 0
>> C:\This\Path\Is\AutoComputed /usr/bin ntfs binary 0 0
>> C:\This\Path\Is\AutoComputed /usr/lib ntfs binary 0 0
> 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.
>> Oh, and I'm guessing that setup-1.7 should create /etc/fstab if "install
>> for all users", and "/etc/fstab.SID" if "just me"? Otherwise, you'll
>> clobber the "old" cygwin's registry entries every time you try to update
>> your "new" cygwin installation...
>That's right. I think this could be done by a simple postinstall script
>which gets called from setup-1.7. Consider a package which comes with
>a default /etc/fstab which consists only of the above entry for the root
>dir. The script would simply add the /usr/bin and /usr/lib entries.
>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?
>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.