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
