This is the mail archive of the
mailing list for the Cygwin project.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
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?
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.
But that still leaves the mount options. Urk.
C:\cygwin\bin /usr/bin ntfs binary 0 0
This is the typical loopback mount /usr/bin from /bin -- but
a) we have already computed the DOS path of /bin -- that's how we
figured out where / should be.
b) We do not support any installation where /usr/bin is NOT a
loopback on /bin.
So...maybe this entry should be automatic, too? Except for the mount
C:\cygwin\lib /usr/lib ntfs binary 0 0
Finally, given all of the above...there's an obvious suggestion with
respect to the /usr/lib loopback mount, as well. Except for the mount
Maybe there should be "special" rules for the three special autocomputed
# 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
C:\cygwin\usr\X11R6\lib\X11\fonts /usr/X11R6/lib/X11/fonts ntfs
binary 0 0
\\fs01\archiv /home/archiv smbfs binary 0 0
cygdrive /mnt auto binary 0 0
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...
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:
I'm thinking specifically of the inetd/syslogd/sshd daemons, but also