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 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.
>
>AOL ;)
>
>>> 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
>
>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.

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

cgf


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