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

[Corinna Vinschen]

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

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

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.


Corinna

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