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

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

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

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
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:
if cygwin_17
then service_name=sshd_17
else service_name=sshd

I'm thinking specifically of the inetd/syslogd/sshd daemons, but also cygserver...


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