Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 8 17:39, Christopher Faylor wrote: On Tue, Apr 08, 2008 at 11:07:26PM +0200, Corinna Vinschen wrote: With a dash? cygwin-ng? Like syslog-ng. I was going to suggest this too, but I didn't want to copy the naming too bluntly. We actually use ng internally to Netapp. I actually wanted to call my project either ds9 or voyager but I got vetoed. I assume Netapp didn't want to risk a law suite with CBS... I guess we should use cygwin-notasnewbutstillnewenough. I'm still more leaning towards cygwin-2008. You shouldn't have suggested the name. It's all your fault. I hate the name! Hate it! But I don't really care. cygwin-2008 is fine with me. However, I predict that cgf-2012 will probably be grumbling about that name eventually. Looks like Brian made this whole naming discussion obsolete two years ago... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 8 23:46, Corinna Vinschen wrote: On Apr 8 14:16, Brian Dessent wrote: Okay, so, several years ago setup.exe HEAD was modified to look for release and release_legacy as the base dirname for packages depending on whether it was running on 9x/ME or NT/2k/etc. I understand Sorry, but I didn't remember that. Why didn't you just tell us? How do you differ the setup.ini files if you only have different release subdirs? setup_legacy.ini? that having Cygwin 1.7 playground is a different concept, but why should it be handled differently? Why not release_1.7? This is all temporary anyway IIUC, since it's just for testing packages built with 1.7, which will eventually all be moved over into just plain release anyway, right? If this is *not* temporary then how does it fit into the idea of having a legacy 9x/ME area? When I came up with that a couple of days ago, I thought it might be bad to rename the current release area for 1.5 so that it keeps working as is and downloading from the 1.7 release area requires to make the conscience choice to use the 1.7 setup. If we can do this with a release-1.7 plus a setup-1.7.ini file, than that's ok for me, too. And, apart from the actual names used, can we get a matching setup.exe perhaps this week? Or the next one? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: Sorry, but I didn't remember that. Why didn't you just tell us? I thought we were talking about two different things. As I see it, here are the *conceptual* things we're dealing with: A) We want to have a tree of packages that is still usable for users of 9x/ME after 1.7 is released, even if it's not updated often or at all. Since setup can determine this at runtime, it can simply decide to fetch a different .ini. B) We want to have a playground where maintainers and advanced users can try out 1.7 and packages built against 1.7, in preparation for the release. C) During that prep period (i.e. right now) we want the standard 1.5 tree to remain and be the default for users. Now, having written that it appears that (A) and (C) are really the same thing. So maybe we only actually have two things: the current tree which will get renamed to _legacy after 1.7 is released, and a new playground which will be promoted to the standard release tree when 1.7 is ready and tested. How do you differ the setup.ini files if you only have different release subdirs? setup_legacy.ini? Sorry, I actually misremembered how this was implemented. The switching happens at the .ini level: #define SETUP_INI_FILENAME (IsWindowsNT () ? setup.ini : setup_legacy.ini) #define SETUP_BZ2_FILENAME (IsWindowsNT () ? setup.bz2 : setup_legacy.bz2) And of course the .ini file contains the filename of the package including the release part: version: 1.5.25-11 install: release/cygwin/cygwin-1.5.25-11.tar.bz2 1427217 e1f969931a1e18855716f2c57c3a876a Thus, setup just looks for a different .ini, the thing on sourceware that generates that ini can decide what the dirs are named. When I came up with that a couple of days ago, I thought it might be bad to rename the current release area for 1.5 so that it keeps working as is and downloading from the 1.7 release area requires to make the conscience choice to use the 1.7 setup. If we can do this with a release-1.7 plus a setup-1.7.ini file, than that's ok for me, too. So it appears this is what we want: For right now/temporary: - standard setup.exe grabs setup.ini/bz2 for both 9x/ME and NT (i.e. no version checking code) - advanced user/maintainer setup.exe grabs setup-1.7.ini/bz2 unconditionally which will be a new tree we create, which contains packages built against 1.7 At point of 1.7 release: - rename setup.ini to setup_legazy.ini - rename setup-1.7.init to setup.ini - release new setup.exe that replaces both of the above, with 9x/ME check enabled (back to one version of setup.exe) Sound about right? And yes, it's rather trivial to release a new setup.exe with the ini name tweaked, so once we decide on that I can upload such to the website. Brian
RE: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., the current code doesn't do right. I called GetModuleFileName(NULL) which returns the path of the current application, not the path of the Cygwin DLL. I'll fix that. [snip] Which is too late for cygrunsrv itself, right? The idea is to avoid having to add the Cygwin bin dir to the system variable %PATH%. If you want to accomplish that, cygrunsrv itself must be independent of it. That's only the case if it shares the bin dir with the Cygwin DLL. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. And cygrunsrv. From earlier discussions it seems that there are some nice to have features in future Cygwin for all sorts of real-life not-only-developer-user reasons: - users plugging in possibly more than one USB key each containing possibly different Cygwins - read-only Samba or Windows shares containing a common Cygwin installation for multiple client computers - 64-bit Windows installations having both 32-bit and 64-bit Cygwin installations As far as I understand it, the current Cygwin runtime architecture uses shared memory for those Cygwin processes attached to the Cygwin DLL, and a static registry location for its static mount table. As already discussed, the static mount table could move out into the Cygwin file system, freeing up any registry conflict for multiple Cygwins. Is it feasible to consider that more than one Cygwin shared memory be created, one for each of multiple Cygwins? Each Cygwin could be uniquely identified by the UNC path to its Cygwin DLL. The static registry location, or indeed another singleton shared memory, could then be used for mapping from Cygwin DLL UNC path to the UNC path to its shared memory. Given that structure, any process using a Cygwin DLL could at Cygwin DLL attach time look in the static registry location or the singleton shared memory to locate its shared memory UNC path, then go on from there to locate its dynamic mount table, security environment, etc., etc. What do you think? Peter Klavins [EMAIL PROTECTED] This email was sent from Netspace Webmail: http://www.netspace.net.au
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Mon, Apr 07, 2008 at 12:34:50AM +1000, [EMAIL PROTECTED] wrote: As far as I understand it, the current Cygwin runtime architecture uses shared memory for those Cygwin processes attached to the Cygwin DLL, and a static registry location for its static mount table. As already discussed, the static mount table could move out into the Cygwin file system, freeing up any registry conflict for multiple Cygwins. Is it feasible to consider that more than one Cygwin shared memory be created, one for each of multiple Cygwins? Each Cygwin could be uniquely identified by the UNC path to its Cygwin DLL. The static registry location, or indeed another singleton shared memory, could then be used for mapping from Cygwin DLL UNC path to the UNC path to its shared memory. Is it feasible? It's just a simple matter of programming but it is not as simple as what you are saying above. is it planned? AFAIK, no. Is this the right mailing list to discuss changes to the architecture of the cygwin DLL? No. cgf
RE: [HEADSUP] Let's start a Cygwin 1.7 release area
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/msg0.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
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 4 14:22, Corinna Vinschen wrote: On Apr 3 17:46, Charles Wilson wrote: Christopher Faylor wrote: Why do we need a fstab.$SID and linux doesn't need this? Well, I like to create user mounts for each user (Guest, Administrator, me) like this: mount -f -u -b C:/Documents and Settings/user/My Documents /mydocs mount -f -u -b C:/Documents and Settings/user/Desktop /desktop [...] I understand that. Well, we shouldn't make this overly public, but keeping the fstab.$SID handling in doesn't hurt the least bit. [...] I just applied a patch which changes the fstab handling somewhat. I made especially a change to how system and user mount points are handled, which is supposed to support sysadmins in commercial or organizational environments. - The paths in the first and second field may contain nuts^Wspaces. You specify them the same way as in a Linux fstab, using the special string \040: C:/Documents\040and\040Settings /my\040docs ntfs binary 0 0 - mount(1) and umount(1) don't write back any information to the registry. Cygwin still reads mount points from the registry, though, if no fstab file exists. This is just left in for the transformation process. It will get removed at one point. - All mount points in /etc/fstab are system mount points by default, all other mount points are always user mount points. The important thing here is, that user mount points can't override system mount points anymore. If you try that, you get an EPERM error. The reason for this change is to allow sysadmins to specify paths in /etc/fstab which no user is allowed to screw up. Paths which the user may umount or re-mount can be marked as user mounts by the admin. - The flags string in the fstab file also understands the flags system and user now, to allow the sysadmin to specify default paths which a user may change. - Cygwin creates /cygdrive as default cygdrive prefix now before reading the fstab files. It's a user mount by default, so the user can override it. If the sysadmin decides to add the cygdrive prefix to /etc/fstab as system mount, no user can override it, but gets an EPERM instead. - The user-specific fstab file is now /etc/fstab.$USER, not /etc/fstab.$SID anymore. My significant other convinced me that nobody(TM) knows what a SID is. I pointed out the Cygwin user's guide, but... - I hacked a new Cygwin postinstall script, which is called postinstall in the Cygwin sources, and which gets copied to /etc/postinstall/000-cygwin-post-install.sh at installation time. It creates a default /etc/fstab file which (for now) contains the standard mount points for /usr/bin and /usr/lib. The script also creates the /dev/shm and /dev/mqueue subdirectories which are required for POSIX semaphores/shared memory/message queues, but that's another story. The /etc/fstab file which gets created by this script contains lots of comment, which is basically taken from Linux' fstab man page. I added Cygwin specifc descriptions and examples. I hope it helps. I would be glad if people could read the text and comment on it. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 20:49, Christopher Faylor wrote: [responding to the thread which started it all] On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. So far so good. - All files in the original release dir are hardlinked into their matching spot in the cygwin-1.7 dir. I don't like hardlinking. It's too easy to have unintended side effects. I think I'd rather just symlink the directories in the new release area then rm the symlink and create a new directory when it's time to populate the directory with a 1.7 version. In theory I agree, but it lets more room for mistakes. It's very easy to have a new package and just move the files to the directory, instead of checking if the directory is a symlink or a real dir. If the dir is a real dir from the start, you just dump the new package into the dir and remove the oldest files and be done. Anyway, it's nothing I really get excited about. - The cygwin subdir gets created and filled with only the first Cygwin DLL 1.7.0 tar files. - Chris starts a second upset which creates the setup.ini file in the cygwin-1.7 dir. I can do this but on top of this, I'd actually like to implement my plan for allowing people to control their own directories. I hadn't thought about adding a 1.7 directory but it should still be doable. If we don't do this, I think we'll be awash in a sea of RFU's and me pulling what little hair I have left out over upset errors. I'd also like to finally have a package lint program which could be invoked automatically. Anyone want to write one of those? I don't want to necessarily gate 1.7 on these things but a package lint is really long overdue, IMO. You could even write one that took a setup.ini as input to make sure that the setup.hint was correct to help stem the tide of upset errors. That's a good idea. Unfortunately I don't have the time right now... Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 17:46, Charles Wilson wrote: Christopher Faylor wrote: Why do we need a fstab.$SID and linux doesn't need this? Well, I like to create user mounts for each user (Guest, Administrator, me) like this: mount -f -u -b C:/Documents and Settings/user/My Documents /mydocs mount -f -u -b C:/Documents and Settings/user/Desktop /desktop mainly for convenience, but also because spaces and the command line don't mix well. Linux doesn't have to deal with asinine decisions made in Redmond, WA...from a hidden microphone in 1995: LOOK! We can support spaces in filenames as well as filenames longer than 8.3, so let's use them EVERYWHERE! Spaces for EVERYBODY! Really long and hard to type system paths, like 'Documents and Settings'! Whoo-pee!! Steve Jobs has got nuthin' on us! I realize that on (clean-install, non-upgrade) Vista, this is less of an issue, because the new paths are mount -f -u -b C:/Users/user/Documents /mydocs mount -f -u -b C:/Users/user/Desktop /desktop but XP and 2k aren't going anywhere for a long long time, if even one of the horror stories I've read about Vista are true... I understand that. Well, we shouldn't make this overly public, but keeping the fstab.$SID handling in doesn't hurt the least bit. Btw., since setup.exe (or the subsequent script) can and will always create an /etc/fstab file, doesn't that mean we can get rid of the choices all users and just me? The only difference between these two choices is in which registry area the mount points go. So there's no reason to stick to that choice. And while we're at it, I don't see any need to stick to the UNIX/DOS choice either. We should always install binary mount points. If the user needs text mounts, there's an editor and a fstab file, right? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
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/msg0.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
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: 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/msg0.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... FWIW: ~/.fstab - No /etc/fstab - Yes and get rid of the registry entirely 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. I think that's the right way to handle this. 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. For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. [...] 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. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. 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. Why do we need a fstab.$SID and linux doesn't need this? 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 :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 09:56, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: - 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... FWIW: ~/.fstab - No I don't think that's as easily implementable as having such a file in /etc anyway, but you're making an important note below, so, see there. /etc/fstab - Yes and get rid of the registry entirely ACK. The reason I implemented this with using the registry as a fallback is for easier testing. The idea is that we (developers and maintainers) can start to use the fstab approach, while normal users on the Cygwin list, who are just curious, still can run a snapshot in their otherwise unchanged environment. On Apr 2 17:56, Charles Wilson wrote: Corinna Vinschen wrote: 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. I think that's the right way to handle this. That puzzles me a bit, because of what you write below. 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. For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. I'm not sure I understand this, that's why I was puzzled above. Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? 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. Why do we need a fstab.$SID and linux doesn't need this? Let me think... I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. 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 :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. How? The mount points are bound to the existance of the shared memory they reside in. This shared mem disappears when the last Cygwin process in a session exits. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] 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. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. [snip] For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Umm, i don't see how that follows. cygrunsrv can easily reside in /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked from the shell, and (b) when cygrunsrv installs the services, it adds /bin to the PATH in the service environment. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. I'm not sure I understand this, that's why I was puzzled above. Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? It is, IMHO. 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. Why do we need a fstab.$SID and linux doesn't need this? Let me think... I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. That, and also to allow completely disjoint Cygwin installations for different users (where the mount table would otherwise be shared). But this effect can also be accomplished with /etc/fstab (one per installation). However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. Yes, that reasoning is mostly correct. However, some packages (like Cygwin/X) apparently assume a single-user installation, and create sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, makes the default startup scripts insufficient to allow multiple users to run Cygwin/X sessions simultaneously, unless that shared location is overridden in a per-user manner (e.g., through user mounts). So, until we figure out how to solve that issue, user mounts are actually userful. Igor -- http://cs.nyu.edu/~pechtcha/ |\ _,,,---,,_[EMAIL PROTECTED] | [EMAIL PROTECTED] ZZZzz /,`.-'`'-. ;-;;,_Igor Peshansky, Ph.D. (name changed!) |,4- ) )-,_. ,\ ( `'-' old name: Igor Pechtchanski '---''(_/--' `-'\_) fL a.k.a JaguaR-R-R-r-r-r-.-.-. Meow! That which is hateful to you, do not do to your neighbor. That is the whole Torah; the rest is commentary. Go and study it. -- Rabbi Hillel
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 11:16, Igor Peshansky wrote: On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] 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. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., the current code doesn't do right. I called GetModuleFileName(NULL) which returns the path of the current application, not the path of the Cygwin DLL. I'll fix that. [snip] For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Umm, i don't see how that follows. cygrunsrv can easily reside in /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked from the shell, and (b) when cygrunsrv installs the services, it adds /bin to the PATH in the service environment. Which is too late for cygrunsrv itself, right? The idea is to avoid having to add the Cygwin bin dir to the system variable %PATH%. If you want to accomplish that, cygrunsrv itself must be independent of it. That's only the case if it shares the bin dir with the Cygwin DLL. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. And cygrunsrv. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. Yes, that reasoning is mostly correct. However, some packages (like Cygwin/X) apparently assume a single-user installation, and create sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, That's a bug in Cygwin/X or in using it. If you have different DISPLAY numbers for different displays, they shouldn't share the /tmp stuff, just like on Linux et al. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
[#$%^! I had a reply-to set in my original reply. I removed it. Please reply to *this* mail. Thanks.] On Apr 3 11:16, Igor Peshansky wrote: On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] 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. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., the current code doesn't do right. I called GetModuleFileName(NULL) which returns the path of the current application, not the path of the Cygwin DLL. I'll fix that. [snip] For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Umm, i don't see how that follows. cygrunsrv can easily reside in /usr/bin, as long as (a) /bin is in the PATH when cygrunsrv is invoked from the shell, and (b) when cygrunsrv installs the services, it adds /bin to the PATH in the service environment. Which is too late for cygrunsrv itself, right? The idea is to avoid having to add the Cygwin bin dir to the system variable %PATH%. If you want to accomplish that, cygrunsrv itself must be independent of it. That's only the case if it shares the bin dir with the Cygwin DLL. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. And cygrunsrv. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. Yes, that reasoning is mostly correct. However, some packages (like Cygwin/X) apparently assume a single-user installation, and create sockets/temp files in shared locations (i.e., /tmp). That, unfortunately, That's a bug in Cygwin/X or in using it. If you have different DISPLAY numbers for different displays, they shouldn't share the /tmp stuff, just like on Linux et al. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 17:38, Corinna Vinschen wrote: On Apr 3 11:16, Igor Peshansky wrote: On Thu, 3 Apr 2008, Corinna Vinschen wrote: [snip] 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. So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. I don't understand this. As discussed somewhat later, if the root dir follows automatically from where the DLL itself resides. Which, btw., [...] Looks like I distracted myself while replying. What I was trying to say is, if the root dir is taken automatically from the path of the DLL, there is no reason to have the path to the root dir stored anywhere, isn't it? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: On Apr 3 09:56, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 11:42:20AM +0200, Corinna Vinschen wrote: - 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... FWIW: ~/.fstab - No I don't think that's as easily implementable as having such a file in /etc anyway, but you're making an important note below, so, see there. /etc/fstab - Yes and get rid of the registry entirely ACK. The reason I implemented this with using the registry as a fallback is for easier testing. The idea is that we (developers and maintainers) can start to use the fstab approach, while normal users on the Cygwin list, who are just curious, still can run a snapshot in their otherwise unchanged environment. On Apr 2 17:56, Charles Wilson wrote: Corinna Vinschen wrote: 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. I think that's the right way to handle this. That puzzles me a bit, because of what you write below. 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. For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Or simply root / ntfs binary 0 0 and stick to /usr/bin and /usr/lib as they are today. I think something like an automount is needed since it would be nice to eventually generalize the cygdrive stuff and we don't want to explicitly mount a: - z: So, maybe we could consider a linux-like solution to accomplish this although I really don't like automount. I'm not sure I understand this, that's why I was puzzled above. Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. 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 :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. How? The mount points are bound to the existance of the shared memory they reside in. This shared mem disappears when the last Cygwin process in a session exits. I have to research what I'm thinking of but I think it's possible. I don't know if it is possible for a non-privileged user though. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 12:11, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. Uh, that's something I didn't look for. I just used the word auto because it sounded nice at this point. Actually the third field is ignored. The important part is the cygdrive in the first field, which is along the lines of, say, proc or sysfs in Linux. We don't have a reason (so far) to care for the FS type field in fstab. 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 :) On XP it should be possible to make it so that the mounts last until reboot. If we can do that I think it would be ideal. How? The mount points are bound to the existance of the shared memory they reside in. This shared mem disappears when the last Cygwin process in a session exits. I have to research what I'm thinking of but I think it's possible. I don't know if it is possible for a non-privileged user though. If you mean to create permanent shared objects, that's not possible for an admin user either without tweaking the security policy. This policy is by default only active for kernel mode code. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: On Apr 3 12:11, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. Uh, that's something I didn't look for. I just used the word auto because it sounded nice at this point. Actually the third field is ignored. The important part is the cygdrive in the first field, which is along the lines of, say, proc or sysfs in Linux. We don't have a reason (so far) to care for the FS type field in fstab. But if we were doing this the right way then I think we probably should have a procfs and something else which allowed the automatic mounting of devices like floppies or usb disks. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 3 12:59, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 06:26:46PM +0200, Corinna Vinschen wrote: On Apr 3 12:11, Christopher Faylor wrote: On Thu, Apr 03, 2008 at 04:19:58PM +0200, Corinna Vinschen wrote: Do you think that / should be free as today: C:\arbitrary\useless\new\path / ntfs binary 0 0 or do you think an automatic approach as the above root / ntfs binary 0 0 is the way to go? As for cygdrives, isn't the cygdrive /mnt auto binary 0 0 already along the lines of an automount?!? auto in /etc/fstab doesn't mean automount. It means that it is meant to be automatically mounted at boot time. That's fine for /, /bin, /usr/bin. It isn't fine for z: where z: is a usb device. Uh, that's something I didn't look for. I just used the word auto because it sounded nice at this point. Actually the third field is ignored. The important part is the cygdrive in the first field, which is along the lines of, say, proc or sysfs in Linux. We don't have a reason (so far) to care for the FS type field in fstab. But if we were doing this the right way then I think we probably should have a procfs and something else which allowed the automatic mounting of devices like floppies or usb disks. I see. I did the evaluation of a mount point being something automatic by using a string in the first field, but actually we should use specific strings in the FS type field and either ignore the content of the first field - for FS types like cygdrive, proc (later) root, sysfs (much later) - or the first field is the device which gets mounted in the second dir if the mount point is auto. Sort of a better cygdrive. I'll change the fstab stuff to do the FS type recognition for cygdrive and root. We can then add the auto and proc stuff easily at some later point. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Christopher Faylor wrote: Why do we need a fstab.$SID and linux doesn't need this? Well, I like to create user mounts for each user (Guest, Administrator, me) like this: mount -f -u -b C:/Documents and Settings/user/My Documents /mydocs mount -f -u -b C:/Documents and Settings/user/Desktop /desktop mainly for convenience, but also because spaces and the command line don't mix well. Linux doesn't have to deal with asinine decisions made in Redmond, WA...from a hidden microphone in 1995: LOOK! We can support spaces in filenames as well as filenames longer than 8.3, so let's use them EVERYWHERE! Spaces for EVERYBODY! Really long and hard to type system paths, like 'Documents and Settings'! Whoo-pee!! Steve Jobs has got nuthin' on us! I realize that on (clean-install, non-upgrade) Vista, this is less of an issue, because the new paths are mount -f -u -b C:/Users/user/Documents /mydocs mount -f -u -b C:/Users/user/Desktop /desktop but XP and 2k aren't going anywhere for a long long time, if even one of the horror stories I've read about Vista are true... -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: On Apr 3 09:56, Christopher Faylor wrote: For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Yep. A few things off the top of my head: 1) the shells need to install both in /bin and /usr/bin. This is up to the individual maintainers when they build their -1.7 versions, but to take on super-duper important shell: C:\cygwin/bin\bash.exe C:\cygwin/bin\cygwin1.dll C:\cygwin/bin\cygintl-8.dll C:\cygwin/bin\cygiconv-2.dll C:\cygwin/bin\cygreadline6.dll C:\cygwin/bin\cygncurses-8.dll Should /bin/bash be built statically (at least with regards libintl/libiconv/libreadline/libncurses)? Should /usr/bin/bash be identical to /bin/bash and also built statically? Or should bash-3.x.y-z.tar.bz2 for cygwin-1.7 have two separate (and different) bash executables in it? What if that tarball (with different /usr/bin/bash and /bin/bash) is unpacked on a system where legacy /usr/bin-/bin mounts are present? Or should some important set of DLL libraries be installed into both /usr/bin/ and /bin, and then /usr/bin/bash.exe and /bin/bash.exe (and /bin/sh.exe) can all be exactly the same, built using dynamic links, just as /usr/bin/bash.exe is today? Or tough. you want to run /bin/bash, ensure /usr/bin is in your PATH 2) build tools (netrel, gbs, cygport) might need a few additions/tweaks to support any of the above. I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. No, please don't...I like my /desktop mount... -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Igor Peshansky wrote: So would it make sense to put the root mount info in the same directory as cygwin1.dll? I know it doesn't belong in /bin, but playing with relative paths is even more error-prone. MSYS has been doing the find msys dll, then locate ../../etc/fstab thing for years. Of all the (many) problems MSYS has, AFAIK this error-prone issue has NEVER been one of them. /bin should contain programs that should work even if the PATH and mounts are screwed up. So, kill, shutdown, etc. But if THAT is the requirement (work if mounts are messed up and -- for instance -- /usr/bin/ can't be found), then they all need to be statically linked (with the exception of /bin/cygwin1.dll, of course) -- or some carefully selected set of DLLs need to be installed in /bin. -- Chuck
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
Corinna Vinschen wrote: /etc/fstab - Yes and get rid of the registry entirely ACK. Upgrading pain could be eased if setup.exe (or a postinstall script, perhaps) detected that /etc/fstab doesn't exist, and created it from the registry entries.
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 06:01:37PM -0500, Charles Wilson wrote: Corinna Vinschen wrote: On Apr 3 09:56, Christopher Faylor wrote: For 1.7, I think we ought to decouple /bin /usr/bin and /lib /usr/lib. The rationale for keeping those linked no longer applies in the modern setup.exe world. Full ACK! However, this needs a bit of careful revisiting of some of the packages. For instance, assuming the Cygwin DLL will go to /bin, cygrunsrv should also reside in /bin when we do this, not in /usr/bin, obviously. Right now I must admit that I prectically don't care if my packages install the binaries in /bin or /usr/bin. Yep. A few things off the top of my head: 1) the shells need to install both in /bin and /usr/bin. This is up to the individual maintainers when they build their -1.7 versions, but to take on super-duper important shell: Or tough. you want to run /bin/bash, ensure /usr/bin is in your PATH Yes. Making duplicate copies is asking for trouble. 2) build tools (netrel, gbs, cygport) might need a few additions/tweaks to support any of the above. I don't know. I assume I just took this as it is. I guess the only reason to create user mounts to begin with was, so that any non-privileged user can create mount points, too, for a pure just me installation in a restricted environment. However, that's not really necessary anymore with /etc/fstab. So I agree, we can simply get rid of fstab.$SID. No, please don't...I like my /desktop mount... You don't need fstab to do mounts. It's always possible to add a mount to your .bashrc or something. That's what you'd do on linux if you wanted similar functionality. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Thu, Apr 03, 2008 at 05:22:51PM -0600, Warren Young wrote: Corinna Vinschen wrote: /etc/fstab - Yes and get rid of the registry entirely ACK. Upgrading pain could be eased if setup.exe (or a postinstall script, perhaps) detected that /etc/fstab doesn't exist, and created it from the registry entries. Yes. I think that is the intent. cgf
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
[responding to the thread which started it all] On Wed, Apr 02, 2008 at 02:35:51PM +0200, Corinna Vinschen wrote: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. So far so good. - All files in the original release dir are hardlinked into their matching spot in the cygwin-1.7 dir. I don't like hardlinking. It's too easy to have unintended side effects. I think I'd rather just symlink the directories in the new release area then rm the symlink and create a new directory when it's time to populate the directory with a 1.7 version. - The cygwin subdir gets created and filled with only the first Cygwin DLL 1.7.0 tar files. - Chris starts a second upset which creates the setup.ini file in the cygwin-1.7 dir. I can do this but on top of this, I'd actually like to implement my plan for allowing people to control their own directories. I hadn't thought about adding a 1.7 directory but it should still be doable. If we don't do this, I think we'll be awash in a sea of RFU's and me pulling what little hair I have left out over upset errors. I'd also like to finally have a package lint program which could be invoked automatically. Anyone want to write one of those? I don't want to necessarily gate 1.7 on these things but a package lint is really long overdue, IMO. You could even write one that took a setup.ini as input to make sure that the setup.hint was correct to help stem the tide of upset errors. cgf
[HEADSUP] Let's start a Cygwin 1.7 release area
Hi, even though Cygwin 1.7 is not yet really ok for a main release, I think that it's time to start a release area for it, so we can start to build Cygwin applications specificially for 1.7. A major advantage is that we will get much more testing, especially when using features which are not at all present in 1.5. Long path names, the LSA module, Linux extended attributes, Vista symlink support, ... more stuff I just don't remember, and, last but definitely not least, IPv6 support. I'm not sure if that's the best way to accomplish this, but here's my idea how to start: - We create a ftp://cygwin.com/pub/cygwin-1.7 dir. - Under that dir, we create the full release directory structure as it exists in the parallel cygwin dir, except for the cygwin itself. - All files in the original release dir are hardlinked into their matching spot in the cygwin-1.7 dir. - The cygwin subdir gets created and filled with only the first Cygwin DLL 1.7.0 tar files. - Chris starts a second upset which creates the setup.ini file in the cygwin-1.7 dir. - The setup.exe team creates a special setup-1.7.exe which will fetch data from the cygwin-1.7 directory. As soon as a maintainer creates a package which has been build under 1.7.0, this package gets copied into the respective directory under the cygwin-1.7 hirarchy. This allows to slowly migrate to the 1.7 release and especially more and more testing and feedback on bugs. When we're confident that we can dare the first actual public release of 1.7, many packages will already be available in a 1.7 specific build and the migration will be more smooth for normal users. Having said that, I would like to ask especially you package maintainers to set up a separate machine or a separate cygwin directory for the 1.7 release. Right now we have the problem that the mount points in the registry are still shared between a 1.5 and a 1.7 release, so you will have to create some batch files to switch the mount points between the two installations, if you do this on a single machine. That's a bit of a hassle, but it's doable, ok? Is there anything wrong or sick with the above procedure? Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
Re: [HEADSUP] Let's start a Cygwin 1.7 release area
On Apr 2 14:35, Corinna Vinschen wrote: Having said that, I would like to ask especially you package maintainers to set up a separate machine or a separate cygwin directory for the 1.7 release. Right now we have the problem that the mount points in the registry are still shared between a 1.5 and a 1.7 release, so you will have to create some batch files to switch the mount points between the two installations, if you do this on a single machine. That's a bit of a hassle, but it's doable, ok? 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. This allows to install a 1.7 Cygwin tree which is independent from a parallel 1.5.x installation in terms of mount points. It's still not a good idea to *run* two parallel DLLs, though. 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 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 C:\cygwin\bin /usr/bin ntfs binary 0 0 C:\cygwin\lib /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 $ cat /etc/fstab.S-1-5-21-1220945662-261903793-725345543-1003 C:\cygwin\home\corinna\textmode-dir /home/corinna/textmode-dir ntfs text 0 0 c:\cygwin\home\corinna\managed /home/corinna/managed ntfs binary,managed 0 0 Leading spaces and tabs are ignored. Spaces and tabs are field separators. Lines starting with a # are skipped. Maximum line length is 64K. Malformed lines are ignored. First string:Native path. The special string cygdrive allows to specify the cygdrive prefix. Max length 260 bytes for now. Second string: POSIX path. For cygdrive the cygdrive prefix. Max length 260 bytes for now. Thirds string: FS type, ignored. Forth string:Flags list, separated by comma. Valid flags: binary,text,exec,notexec,cygexec,nosuid,managed. For a description, see Cygwin's `man mount' Fifth and sixth string: Ignored. FAQ: Q: Where do I get my SID from? A: See your /etc/passwd entry, the string starting with S-1-. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat
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 fi etc. I'm thinking specifically of the inetd/syslogd/sshd daemons, but also cygserver... -- Chuck
