RE: cygwin.com suggestions
> -Original Message- > From: [EMAIL PROTECTED] > > Here are a couple of suggestions for making the cygwin.com > website more > helpful. Thanks for your suggestions, feedback on them in-line. > 1) Include the current version number of setup.exe on the front page. > Otherwise, there is no way for the infrequent visitor to the > website to > know if setup.exe has been updated other than to re-download > and run it. Setup.exe will warn you if it is out of date - the online data includes the current version of setup.exe in the ini file. Having the version number on the website is thus redudant. > 2) Include in the FAQ (or somewhere) a section on "How to > Safely Update the > Cygwin dll". Probably just "shut down all cygwin apps, > including daemons", > but it would be useful to know for sure. The next release of setup.exe automatically address's this and will replace in-use .dll's. > 3) Include or link those instructions in announcements of new > Cygwin dll > releases. > > Do these make sense? They do, but as you can see we already have in place other measures to address the same issues. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.com suggestions
Robert Collins wrote: >>2) Include in the FAQ (or somewhere) a section on "How to >>Safely Update the >>Cygwin dll". Probably just "shut down all cygwin apps, >>including daemons", >>but it would be useful to know for sure. > > The next release of setup.exe automatically address's this and will > replace in-use .dll's. Really? How does it do that? Because I was under the impression that if a program was running you cannot replace it's .exe file (or .dll file) because it was opened exclusively by Windows. How do you get around that? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.com suggestions
At 02:58 PM 3/15/2002, Andrew DeFaria wrote: >Robert Collins wrote: > >>>2) Include in the FAQ (or somewhere) a section on "How to Safely Update the Cygwin >dll". Probably just "shut down all cygwin apps, including daemons", but it would be >useful to know for sure. >>The next release of setup.exe automatically address's this and will >>replace in-use .dll's. > >Really? How does it do that? Because I was under the impression that if a program was >running you cannot replace it's .exe file (or .dll file) because it was opened >exclusively by Windows. How do you get around that? Same way as Windows installers work. Just schedule the DLL to be moved in after reboot. Larry Hall [EMAIL PROTECTED] RFK Partners, Inc. http://www.rfk.com 838 Washington Street (508) 893-9779 - RFK Office Holliston, MA 01746 (508) 893-9889 - FAX -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.com suggestions
Larry Hall (RFK Partners, Inc) wrote: > At 02:58 PM 3/15/2002, Andrew DeFaria wrote: > >>Robert Collins wrote: >> >> 2) Include in the FAQ (or somewhere) a section on "How to Safely Update the Cygwin >dll". Probably just "shut down all cygwin apps, including daemons", but it would be >useful to know for sure. >>>The next release of setup.exe automatically address's this and will >>>replace in-use .dll's. >>> >>Really? How does it do that? Because I was under the impression that if a program >was running you cannot replace it's .exe file (or .dll file) because it was opened >exclusively by Windows. How do you get around that? > > Same way as Windows installers work. Just schedule the DLL to be moved in > after reboot. But that doesn't really replace the current DLL. IOW the changes are not effective until one reboots. Personally I find this a crummy way to do things but perhaps that's all that can be done. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.com suggestions
> 2) Include in the FAQ (or somewhere) a section on "How to Safely Update the Cygwin dll". Probably just "shut down all cygwin apps, including daemons", but it would be useful to know for sure. > > >>>The next release of setup.exe automatically address's this and will > >>>replace in-use .dll's. > >>> > >>Really? How does it do that? Because I was under the impression that if a program was running you cannot replace it's .exe file (or .dll file) because it was opened exclusively by Windows. How do you get around that? > > > > Same way as Windows installers work. Just schedule the DLL to be moved in > > after reboot. > > But that doesn't really replace the current DLL. IOW the changes are not > effective until one reboots. Personally I find this a crummy way to do > things but perhaps that's all that can be done. Under Win NT/2k/XP it is actually possible to replace a DLL file that's currently in use without rebooting. You rename the existing file to something else, then copy the new file in its place. Then add the old file to the MoveFileEx list of files to delete on reboot. That way the new file is installed straight away. Regards Chris -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin.com suggestions
You cannot rename the existing file if it is in use. I found out the hard way :) Stephano Mariani > -Original Message- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf > Of Chris January > Sent: Friday, 15 March 2002 11:34 PM > To: [EMAIL PROTECTED] > Subject: Re: cygwin.com suggestions > > > >>>>2) Include in the FAQ (or somewhere) a section on "How to Safely > Update the Cygwin dll". Probably just "shut down all cygwin apps, > including > daemons", but it would be useful to know for sure. > > >>>> > > >>>The next release of setup.exe automatically address's this and will > > >>>replace in-use .dll's. > > >>> > > >>Really? How does it do that? Because I was under the impression that > if > a program was running you cannot replace it's .exe file (or .dll file) > because it was opened exclusively by Windows. How do you get around that? > > > > > > Same way as Windows installers work. Just schedule the DLL to be > moved > in > > > after reboot. > > > > But that doesn't really replace the current DLL. IOW the changes are not > > effective until one reboots. Personally I find this a crummy way to do > > things but perhaps that's all that can be done. > Under Win NT/2k/XP it is actually possible to replace a DLL file that's > currently in use without rebooting. You rename the existing file to > something else, then copy the new file in its place. Then add the old file > to the MoveFileEx list of files to delete on reboot. That way the new file > is installed straight away. > > Regards > Chris > > > > -- > Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple > Bug reporting: http://cygwin.com/bugs.html > Documentation: http://cygwin.com/docs.html > FAQ: http://cygwin.com/faq/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.com suggestions
On Fri, Mar 15, 2002 at 11:34:07PM -, Chris January wrote: >Under Win NT/2k/XP it is actually possible to replace a DLL file that's >currently in use without rebooting. You rename the existing file to >something else, then copy the new file in its place. Then add the old file >to the MoveFileEx list of files to delete on reboot. That way the new file >is installed straight away. it's possible to install a new version of the cygwin DLL over an in-use version in some cases. However, you'll cause problems for all running cygwin apps if you use this method. It's safer to reboot. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin.com suggestions
> -Original Message- > From: Chris January [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 16, 2002 10:34 AM > > But that doesn't really replace the current DLL. IOW the > changes are > > not effective until one reboots. Personally I find this a > crummy way to do things but perhaps that's all that can be done. > Under Win NT/2k/XP it is actually possible to replace a DLL > file that's currently in use without rebooting. No its not - a rename operation on a memorymapped file fails. It's under win16 *cough* win9x->Me that memorymapped files can be renamed or deleted. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin.com suggestions
> -Original Message- > From: Andrew DeFaria [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 16, 2002 10:06 AM > > Same way as Windows installers work. Just schedule the DLL to be > > moved in > > after reboot. > > But that doesn't really replace the current DLL. IOW the > changes are not > effective until one reboots. Personally I find this a crummy > way to do > things but perhaps that's all that can be done. I think crummy is a little harsh. And yes, other than shutting down all process's using a file, this is the best that can be done (*). Rob *: Well, it's possible that a file system filter driver that redirects the access to a new file for subsequent opens could provide equivalent functionality to a linux style delete/replace of in-use files. However I don't know whether the file system cache/file mapping logic sit above or below such filters... if they sit above the filter (And I suspect they do), then the filter would never get invoked, and the file would still appear to be there. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.com suggestions
On Sat, Mar 16, 2002 at 12:48:41PM +1100, Robert Collins wrote: > > >> -Original Message- >> From: Chris January [mailto:[EMAIL PROTECTED]] >> Sent: Saturday, March 16, 2002 10:34 AM > >> > But that doesn't really replace the current DLL. IOW the >> changes are >> > not effective until one reboots. Personally I find this a >> crummy way to do things but perhaps that's all that can be done. > >> Under Win NT/2k/XP it is actually possible to replace a DLL >> file that's currently in use without rebooting. >No its not - a rename operation on a memorymapped file fails. It's under >win16 *cough* win9x->Me that memorymapped files can be renamed or >deleted. It works fine on XP. I do it on an almost daily basis when I'm installing new DLLs. It worked fine on NT 4 and W2K, too. I just verified this by doing the following command: cd c:\cygwin\bin mv cygwin1.dll cygwinfoo.dll cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin.com suggestions
> -Original Message- > From: Christopher Faylor [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 16, 2002 2:29 PM > >No its not - a rename operation on a memorymapped file fails. It's > >under win16 *cough* win9x->Me that memorymapped files can be > renamed or > >deleted. > > It works fine on XP. I do it on an almost daily basis when > I'm installing new DLLs. > > It worked fine on NT 4 and W2K, too. > > I just verified this by doing the following command: > > cd c:\cygwin\bin > mv cygwin1.dll cygwinfoo.dll Strange. I'll look more deeply at what I've observed before then. Thanks Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin.com suggestions
[snip] > > But that doesn't really replace the current DLL. IOW the > > changes are not > > effective until one reboots. Personally I find this a crummy > > way to do > > things but perhaps that's all that can be done. > > I think crummy is a little harsh. And yes, other than shutting down all > process's using a file, this is the best that can be done (*). > > Rob > > *: Well, it's possible that a file system filter driver that redirects > the access to a new file for subsequent opens could provide equivalent > functionality to a linux style delete/replace of in-use files. However I > don't know whether the file system cache/file mapping logic sit above or > below such filters... if they sit above the filter (And I suspect they > do), then the filter would never get invoked, and the file would still > appear to be there. > PAIN! WINDOWS... DRIVERS! FILE... SYSTEM... AHA!!! Actually I was thinking this would be a perfect job for that snazzy new daemon coming down the pike; queue the file in question up with the daemon, and have the daemon wait until nobody's looking (i.e. nothing's using the file-to-be-replaced), and then swap the new one in. The daemon could replace itself in a somewhat similar manner; the new daemon would send the old daemon a signal to shut down and then replace it with itself when Windows eventually let go of it. -- Gary R. Van Sickle Brewer. Patriot. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: cygwin.com suggestions
> -Original Message- > From: Gary R. Van Sickle [mailto:[EMAIL PROTECTED]] > Sent: Saturday, March 16, 2002 4:14 PM > PAIN! WINDOWS... DRIVERS! FILE... SYSTEM... AHA!!! > > Actually I was thinking this would be a perfect job for that > snazzy new daemon coming down the pike; queue the file in > question up with the daemon, and have the daemon wait until > nobody's looking (i.e. nothing's using the > file-to-be-replaced), and then swap the new one in. The > daemon could replace itself in a somewhat similar manner; the > new daemon would send the old daemon a signal to shut down > and then replace it with itself when Windows eventually let go of it. Yeah... I've actually written proof-of-concept code for setup.exe to do just that. (Imagine setup.exe self-updating and living in /usr/bin.) However there are a number of things that make me go urgh with this. 1) new-foo exports symbol bar that is needed by the post-install script. When should the script run? (This is an issue today btw). 2) new-foo exports symbol bar that is needed by other userland app. How do we tell the user that they can't run that app until all programs have been shut down? 3) It's similar to the file-delete-queue hack in cygwin, and whilst that is quite successful, it's not seamless. I'd rather be _real_ simple about it. I.e. Offer a choice: reboot after the install or close app foo now. The user does one or the other, not a hybrid (close app foo after the install). Of course, a patch to do it will be treated very differently to ideas :}. Rob -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: cygwin.com suggestions
On Sat, Mar 16, 2002 at 04:30:06PM +1100, Robert Collins wrote: >I'd rather be _real_ simple about it. I.e. Offer a choice: reboot >after the install or close app foo now. The user does one or the >other, not a hybrid (close app foo after the install). I think those are the only sane choices, actually, since replacing a cygwin DLL while it is in use will potentially have disastrous consequences. You might be able to get away with doing it with something like bash, but even that is a potential problem. >Of course, a patch to do it will be treated very differently to ideas >:}. Hmm. I like the sound of that. cgf -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
