RE: [HEADSUP] Let's start a Cygwin 1.7 release area

[Karl M <karlm30@hotmail.com>]

Hi All...

I like this!!!

> Date: Thu, 3 Apr 2008 11:42:20 +0200
> From: corinna
> Subject: Re: [HEADSUP] Let's start a Cygwin 1.7 release area
>
> 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...
>
> 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.. 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., 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.
>
>>> 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.
>
>> [...]
>> 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.
>
>> 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.
For multiple "Just Me" installations?
>
> 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 :)
>
>> One little wrinkle that makes switching between two cygwin installations
>> difficult: services. Do you
>>
>> (1) stop/uninstall -- switch-to-other-cygwin -- reinstall/start as part of
>> each switch, or
>>
>> (2) somehow change each service's target path (and PATH environment
>> variable, if the service.exe is not in /bin. For the proposed 1.7.0 you
>> have to ensure that the "correct" cygwin1.dll is used), and then restart?
>>
>> (3) install services under different names for the two installations, and
>> just remember to stop all the old ones, before trying to use any tools from
>> the "new" installation, and restart the "new" services under their
>> alternate installation names? The installation part of this proposal could
>> be automated in the foo-config scripts:
>> if cygwin_17
>> then service_name=sshd_17
>> else service_name=sshd
>> fi
>> etc.
>
> Consider that a parallel installation is not really for the normal user.
> My answer to this question is, whatever is most convenient for you.
> Personally I tend to option 3, without the changes in the foo-config
> scripts. I'd do the second service installation manually. It's not
> that hard.
>
I think that I prefer (1). I have cygwin-shutdown and cygwin-startup scripts
anyway, because it makes stopping and starting to run setup easier...so this
is no different. I actually uninstall and reinstall the services in my cygwin-startup
script so that the path gets updated if I install/uninstall any other software. I
have one fewer thing to remember that way.
>
...Karl
_________________________________________________________________
Get in touch in an instant. Get Windows Live Messenger now.
http://www.windowslive.com/messenger/overview.html?ocid=TXT_TAGLM_WL_Refresh_getintouch_042008