Re: SETUP: In-use files have been replaced
On Wed, Oct 19, 2005 at 08:15:14PM +0100, Chris Taylor wrote: Herb Martin wrote: Eric Blake wrote: Herb Martin wrote: So what is the method to teach Setup that the file has been updated. Have you tried simply uninstalling the Cygwin package? If you installed the new one into another location, you presumably don't need or want the other one. For most packages at least, SETUP doesn't automatically try to update it if you haven't installed it. I didn't install Exim 4.54 into another location; someone else mentioned an alternate locationa and I (perhaps incorrectly) mentioned that I had downloaded and compiled it FROM another location. The make install was run normally and the specially compiled (make options) is in the default (/usr/bin) location. All I wish to do is make Setup aware of this if it is possible. For now, I must (carefully) ensure that setup doesn't overwrite my good version with the default. If you reinstalled all of exim, you don't really need the cygwin version.. So you want to edit the /etc/setup/installed.db and give it an artificially high number, say 99.999, as the installed version of exim. This will stop cygwin from ever overwriting your installation of exim (unless the version ever gets higher than that.. unlikely in our lifetimes to be honest) Are you sure? I didn't think setup actually compared versions at all. There's been discussion on cygwin-apps of updating packages to a lower version number that is actually a neweer version, and people didn't seem to think there would be any problem with that... -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
Yitzchak Scott-Thoennes wrote: On Wed, Oct 19, 2005 at 08:15:14PM +0100, Chris Taylor wrote: Herb Martin wrote: Eric Blake wrote: Herb Martin wrote: So what is the method to teach Setup that the file has been updated. Have you tried simply uninstalling the Cygwin package? If you installed the new one into another location, you presumably don't need or want the other one. For most packages at least, SETUP doesn't automatically try to update it if you haven't installed it. I didn't install Exim 4.54 into another location; someone else mentioned an alternate locationa and I (perhaps incorrectly) mentioned that I had downloaded and compiled it FROM another location. The make install was run normally and the specially compiled (make options) is in the default (/usr/bin) location. All I wish to do is make Setup aware of this if it is possible. For now, I must (carefully) ensure that setup doesn't overwrite my good version with the default. If you reinstalled all of exim, you don't really need the cygwin version.. So you want to edit the /etc/setup/installed.db and give it an artificially high number, say 99.999, as the installed version of exim. This will stop cygwin from ever overwriting your installation of exim (unless the version ever gets higher than that.. unlikely in our lifetimes to be honest) Are you sure? I didn't think setup actually compared versions at all. There's been discussion on cygwin-apps of updating packages to a lower version number that is actually a neweer version, and people didn't seem to think there would be any problem with that... Well, I find that Eric tends to be pretty reliable, and I have to say that I cannot think of a logical reason why setup *wouldn't* use this method. It makes no sense not to - you'd have to add yet another set of information to setup for it to know if a version was newer. I sincerely doubt that the original setup developers obfuscated it *that* much. The version number is the best way of doing things.. If things change, generally the package name changes slightly as well, and you just make the new one replace the old... (NB: I'm not 100% sure w/o referring to earlier messages that it was Eric that originally posted this (in this thread), but I'm pretty sure it was.) Anyway. Chris -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
On Mon, Oct 24, 2005 at 12:34:30AM +0100, Chris Taylor wrote: Yitzchak Scott-Thoennes wrote: On Wed, Oct 19, 2005 at 08:15:14PM +0100, Chris Taylor wrote: If you reinstalled all of exim, you don't really need the cygwin version.. So you want to edit the /etc/setup/installed.db and give it an artificially high number, say 99.999, as the installed version of exim. This will stop cygwin from ever overwriting your installation of exim (unless the version ever gets higher than that.. unlikely in our lifetimes to be honest) Are you sure? I didn't think setup actually compared versions at all. There's been discussion on cygwin-apps of updating packages to a lower version number that is actually a neweer version, and people didn't seem to think there would be any problem with that... Well, I find that Eric tends to be pretty reliable, and I have to say that I cannot think of a logical reason why setup *wouldn't* use this method. It makes no sense not to - you'd have to add yet another set of information to setup for it to know if a version was newer. I sincerely doubt that the original setup developers obfuscated it *that* much. The version number is the best way of doing things.. If things change, generally the package name changes slightly as well, and you just make the new one replace the old... Ah, but versions are strings, not numbers, and how to compare them isn't always obvious. (NB: I'm not 100% sure w/o referring to earlier messages that it was Eric that originally posted this (in this thread), but I'm pretty sure it was.) Yes, it was: On Wed, Oct 19, 2005 at 06:38:21AM -0600, Eric Blake wrote: According to Herb Martin on 10/18/2005 5:53 PM: So what is the method to teach Setup that the file has been updated. Why does setup need to be taught? However, you may be looking for /etc/setup/installed.db; edit that for the package in question to tell setup.exe that the installed version has the same version number (or greater) than what setup.exe can offer from the mirrors. But I don't think this will work; as an example, there was recently a libIDL package that had a version 0.8.3 but a new version 0.5.17 was released to replace it; setup correctly removed the 0.8.3 and installed the 0.5.17. Also, note that setup in curr mode will always try to upgrade exp packages back to the curr level. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 According to Herb Martin on 10/18/2005 5:53 PM: The context of the discussion was in use files requiring a reboot to complete the update so (obviously) I mean: Would it be considered a bug if all CygWin services, shells, and apps are shutdown but a reboot is still required by Setup? Setup requires a reboot only when Windows reports that a file that was being replaced was in use at the time. Therefore, if setup requires a reboot, then you didn't properly shut down all cygwin services, shells, and apps. I had to use source to compile a module with different from default options. How can that module be installed so that Setup will STOP trying to replace it? Don't use the same location as the packaged version. The normal plan of attack is to install something into the /usr/local hierarchy if you intend for your version to trump the distro's version (in fact, most packages choose this by default if you don't pass any arguments to ./configure) - here, if you pick up an update from the distro, your (now older) version will still be used. On the other hand, install something into the /usr hierarchy if you intend to replace the distro's version with your own, where an update from the distro will wipe out your update. So what is the method to teach Setup that the file has been updated. Why does setup need to be taught? However, you may be looking for /etc/setup/installed.db; edit that for the package in question to tell setup.exe that the installed version has the same version number (or greater) than what setup.exe can offer from the mirrors. - -- Life is short - so eat dessert first! Eric Blake [EMAIL PROTECTED] -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (Cygwin) Comment: Public key at home.comcast.net/~ericblake/eblake.gpg Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDVj4984KuGfSFAYARAlEyAJwIMU7vojuzChCqkrsRaIEjk4vAswCdG1R1 3z4kg29qWcSg6eoxr3ypCtI= =7+57 -END PGP SIGNATURE- -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
Eric Blake wrote: I believe you are referring to the recent question about whether cygwin services must be stopped during a WINDOWS upgrade, My mistake. Thanks for the script. gsw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
Eric Blake wrote: Setup requires a reboot only when Windows reports that a file that was being replaced was in use at the time. Therefore, if setup requires a reboot, then you didn't properly shut down all cygwin services, shells, and apps. Probably true 99.9% of the time, although couldn't it also be possible that another Windows program is opening a Cygwin file in a mode that prevents deletion? (I haven't tried it, but I wouldn't be surprised to get this message if you're viewing a directory that is being uninstalled.) Herb Martin wrote: So what is the method to teach Setup that the file has been updated. Have you tried simply uninstalling the Cygwin package? If you installed the new one into another location, you presumably don't need or want the other one. For most packages at least, SETUP doesn't automatically try to update it if you haven't installed it. gsw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
Herb Martin wrote: I didn't install Exim 4.54 into another location; someone else mentioned an alternate locationa and I (perhaps incorrectly) mentioned that I had downloaded and compiled it FROM another location. The make install was run normally and the specially compiled (make options) is in the default (/usr/bin) location. All I wish to do is make Setup aware of this if it is possible. For now, I must (carefully) ensure that setup doesn't overwrite my good version with the default. There is no way to do that. You will have to either *install* it in a different directory or continue doing what you have been doing. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
Herb Martin wrote: Eric Blake wrote: Herb Martin wrote: So what is the method to teach Setup that the file has been updated. Have you tried simply uninstalling the Cygwin package? If you installed the new one into another location, you presumably don't need or want the other one. For most packages at least, SETUP doesn't automatically try to update it if you haven't installed it. I didn't install Exim 4.54 into another location; someone else mentioned an alternate locationa and I (perhaps incorrectly) mentioned that I had downloaded and compiled it FROM another location. The make install was run normally and the specially compiled (make options) is in the default (/usr/bin) location. All I wish to do is make Setup aware of this if it is possible. For now, I must (carefully) ensure that setup doesn't overwrite my good version with the default. If you reinstalled all of exim, you don't really need the cygwin version.. So you want to edit the /etc/setup/installed.db and give it an artificially high number, say 99.999, as the installed version of exim. This will stop cygwin from ever overwriting your installation of exim (unless the version ever gets higher than that.. unlikely in our lifetimes to be honest) Chris -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
Chris Taylor All I wish to do is make Setup aware of this if it is possible. For now, I must (carefully) ensure that setup doesn't overwrite my good version with the default. If you reinstalled all of exim, you don't really need the cygwin version.. So you want to edit the /etc/setup/installed.db and give it an artificially high number, say 99.999, as the installed version of exim. This will stop cygwin from ever overwriting your installation of exim (unless the version ever gets higher than that.. unlikely in our lifetimes to be honest) Chris Thank you Chris, that is precisely the information I was seeking. -- Herb Martin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
Herb Martin wrote: Chris Taylor All I wish to do is make Setup aware of this if it is possible. For now, I must (carefully) ensure that setup doesn't overwrite my good version with the default. If you reinstalled all of exim, you don't really need the cygwin version.. So you want to edit the /etc/setup/installed.db and give it an artificially high number, say 99.999, as the installed version of exim. This will stop cygwin from ever overwriting your installation of exim (unless the version ever gets higher than that.. unlikely in our lifetimes to be honest) Chris Thank you Chris, that is precisely the information I was seeking. No problem Herb, but I only knew that because Eric mentioned it 4 or 5 messages prior to me in this thread - as a way to prevent setup from updating the package. At that time though, I don't believe it was clear that you'd updated ALL of exim (or indeed what package it was). We thought you'd updated a single file or something - a lib for example. Anyway, glad you're sorted now. Chris -- Spinning complacently in the darkness, covered and blinded by a blanket of little lives, false security has lulled the madness of this world into a slumber. Wake up! An eye is upon you, staring straight down and keenly through, seeing all that you are and everything that you will never be. Yes, an eye is upon you, an eye ready to blink. So face forward, with arms wide open and mind reeling. Your future has arrived... Are you ready to go? -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
Every time I update the cygwin package, I get a warning that in-use
files have been replaced and that I should reboot. I assume this is
caused by a Cygwin service, although at one point somebody on this
list (I think it was Corinna) said that SETUP stops these services
automatically. So I'm assuming my situation isn't normal.
Your situation isn't normal because you didn't stop all cygwin
services. While the idea has been tossed around on this list
that it would be nice if setup.exe could stop services for you,
to date, it does not. Therefore, IT IS UP TO YOU to stop services
beforehand. Or provide a patch so that setup.exe can do
it for you (and for the rest of us).
I use this handy little script on my machine to help me stop
(and restart) all services:
$ cat serv
#!/bin/bash
usage='serv: manage cygwin services during cygwin upgrades
usage: serv {--help|--stop|--start}'
case $# in
1) case $1 in
--help|-h) echo $usage; exit 0 ;;
--stop) for service in `cygrunsrv --list` inetd ; do
echo stopping $service
cygrunsrv --stop $service || echo problems with $service ;;
done ;;
--start) for service in `cygrunsrv --list` inetd ; do
echo starting $service
cygrunsrv --start $service || echo problems with $service
done ;;
esac ;;
*) echo $usage; exit 1 ;;
esac
I've been working around this by carefully updating only the base
cygwin package and rebooting before updating the rest. Whenever I
forget to do this, post-install scripts generally fail and I have
to clean up by running them manually, etc.
That is a reasonable solution (in that you at least guarantee that
you have the latest cygwin before any other new package
postinstall tries to run), but who likes rebooting?
My cygcheck.out is attached.
It would be nice if you could fix your mailer to send attachments
as plain text, and not application/octet-stream.
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
I use this handy little script on my machine to help me stop
(and restart) all services:
It would help if I didn't paste it wrong (I was using a nested case
in my version, to special case one of my own services that is not
a cygwin standard, and didn't completely strip the nested case
before posting):
$ cat serv
#!/bin/bash
usage='serv: manage cygwin services during cygwin upgrades
usage: serv {--help|--stop|--start}'
case $# in
1) case $1 in
--help|-h) echo $usage; exit 0 ;;
--stop) for service in `cygrunsrv --list` inetd ; do
echo stopping $service
cygrunsrv --stop $service || echo problems with $service ;;
There should not be a ;; on this line.
done ;;
--start) for service in `cygrunsrv --list` inetd ; do
echo starting $service
cygrunsrv --start $service || echo problems with $service
done ;;
esac ;;
*) echo $usage; exit 1 ;;
esac
--
Eric Blake
--
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Problem reports: http://cygwin.com/problems.html
Documentation: http://cygwin.com/docs.html
FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
Eric Blake wrote: Your situation isn't normal because you didn't stop all cygwin services. While the idea has been tossed around on this list that it would be nice if setup.exe could stop services for you, to date, it does not. Therefore, IT IS UP TO YOU to stop services beforehand. Thanks. I remember one of the Cygwin major contributors indicating that (s)he didn't find the need to stop the Cygwin services first, but perhaps I misunderstood. gsw -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
Your situation isn't normal because you didn't stop all cygwin services. While the idea has been tossed around on this list that it would be nice if setup.exe could stop services for you, to date, it does not. Therefore, IT IS UP TO YOU to stop services beforehand. Thanks. I remember one of the Cygwin major contributors indicating that (s)he didn't find the need to stop the Cygwin services first, but perhaps I misunderstood. I believe you are referring to the recent question about whether cygwin services must be stopped during a WINDOWS upgrade, which is a different matter entirely from cygwin upgrades. The answer there was that it is usually safe to leave cygwin running during a windows upgrade, although the recent directx 9 patch on Win2k proved to be a counterexample. But when it comes to running cygwin while upgrading cygwin, the consensus on this list is that it is safest and simplest to just always stop all cygwin processes before starting setup.exe. -- Eric Blake -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
cygrunsrv --list Access is denied (Was: Re: SETUP: In-use files have been replaced)
Eric Blake wrote:
I use this handy little script on my machine to help me stop
(and restart) all services:
$ cat serv
#!/bin/bash
usage='serv: manage cygwin services during cygwin upgrades
usage: serv {--help|--stop|--start}'
case $# in
1) case $1 in
--help|-h) echo $usage; exit 0 ;;
--stop) for service in `cygrunsrv --list` inetd ; do
echo stopping $service
cygrunsrv --stop $service || echo problems with $service ;;
done ;;
--start) for service in `cygrunsrv --list` inetd ; do
echo starting $service
cygrunsrv --start $service || echo problems with $service
done ;;
esac ;;
*) echo $usage; exit 1 ;;
esac
Every time I try to list services using cygrunsrv, I get an error:
$ cygrunsrv --list
cygrunsrv: Error enumerating services: OpenService: Win32 error 5:
Access is denied.
Cygwin Configuration Diagnostics
Current System Time: Tue Oct 18 15:38:30 2005
Windows XP Professional Ver 5.1 Build 2600 Service Pack 2
Path: C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
C:\WINDOWS\system32
C:\WINDOWS
C:\WINDOWS\System32\Wbem
C:\Program Files\Common Files\GTK\2.0\bin
C:\Program Files\Perforce
Output from C:\cygwin\bin\id.exe (nontsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root) 544(Administrators) 545(Users)
10513(Domain Users)
Output from C:\cygwin\bin\id.exe (ntsec)
UID: 11643(rcampbell)GID: 10513(Domain Users)
0(root) 544(Administrators) 545(Users)
10513(Domain Users)
SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS
USER = `rcampbell'
PWD = `/tmp'
HOME = `/home/rcampbell'
MAKE_MODE = `unix'
HOMEPATH = `\Documents and Settings\rcampbell'
MANPATH = `/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man'
APPDATA = `C:\Documents and Settings\rcampbell\Application Data'
HOSTNAME = `desk-rcampbell2'
TERM = `xterm'
PROCESSOR_IDENTIFIER = `x86 Family 15 Model 3 Stepping 3, GenuineIntel'
WINDIR = `C:\WINDOWS'
WINDOWID = `4819216'
OLDPWD = `/home/rcampbell'
USERDOMAIN = `TROPICNETWORKS'
OS = `Windows_NT'
ALLUSERSPROFILE = `C:\Documents and Settings\All Users'
TEMP = `/tmp'
COMMONPROGRAMFILES = `C:\Program Files\Common Files'
USERNAME = `rcampbell'
PROCESSOR_LEVEL = `15'
FP_NO_HOST_CHECK = `NO'
SYSTEMDRIVE = `C:'
USERPROFILE = `C:\Documents and Settings\rcampbell'
CLIENTNAME = `Console'
PS1 = `\[\e]0;[EMAIL PROTECTED] \[\e[33m\]\w\[\e[0m\]\n\$ '
LOGONSERVER = `\\OTTDC1'
PROCESSOR_ARCHITECTURE = `x86'
SHLVL = `1'
COLORFGBG = `0;default;15'
TROPIC_UNIQUE_ID = `156'
USERDNSDOMAIN = `TROPICNETWORKS.COM'
PATHEXT = `.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH'
HOMEDRIVE = `C:'
COMSPEC = `C:\WINDOWS\system32\cmd.exe'
TMP = `/tmp'
SYSTEMROOT = `C:\WINDOWS'
PRINTER = `\\spooler\135MC-4th'
CVS_RSH = `/bin/ssh'
PROCESSOR_REVISION = `0303'
INFOPATH = `/usr/local/info:/usr/share/info:/usr/info:'
PROGRAMFILES = `C:\Program Files'
DISPLAY = `:0'
COSMIC = `t'
NUMBER_OF_PROCESSORS = `2'
SESSIONNAME = `Console'
P4CONFIG = `.p4config'
COMPUTERNAME = `DESK-RCAMPBELL2'
COLORTERM = `rxvt-xpm'
_ = `/usr/bin/cygcheck'
POSIXLY_CORRECT = `1'
HKEY_CURRENT_USER\Software\Cygnus Solutions
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\mounts v2
HKEY_CURRENT_USER\Software\Cygnus Solutions\Cygwin\Program Options
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2
(default) = `/cygdrive'
cygdrive flags = 0x0022
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/
(default) = `C:\cygwin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/a
(default) = `A:'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/bin
(default) = `C:\cygwin\bin'
flags = 0x004a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/c
(default) = `C:'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/d
(default) = `C:\d'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/tmp
(default) = `D:\tmp'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/bin
(default) = `C:\cygwin\bin'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\mounts v2\/usr/lib
(default) = `C:\cygwin/lib'
flags = 0x000a
HKEY_LOCAL_MACHINE\SOFTWARE\Cygnus Solutions\Cygwin\Program Options
c: hd NTFS 38162Mb 55% CP CS UN PA FC
d: hd NTFS152632Mb 14% CP CS UN PA FC MegaFast
C:\cygwin / system binmode
A: /a system binmode
C:\cygwin\bin /bin system binmode,cygexec
C: /c system binmode
C:\d /d system binmode
D:\tmp /tmp system binmode
C:\cygwin\bin /usr/bin system binmode
C:\cygwin/lib
Re: cygrunsrv --list Access is denied (Was: Re: SETUP: In-use files have been replaced)
Rolf Campbell wrote: Every time I try to list services using cygrunsrv, I get an error: $ cygrunsrv --list cygrunsrv: Error enumerating services: OpenService: Win32 error 5: Access is denied. That means that there is some service that you do not have access to. When cygrunsrv goes to try to get information on it with OpenService it is denied access. You'd have to run it with a debugger to find out more details. I've been meaning to work on a patch that turns this error into a warning so that it can just keep going if it runs into this problem. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
Eric Blake wrote: Your situation isn't normal because you didn't stop all cygwin services. While the idea has been tossed around on this list that it would be nice if setup.exe could stop services for you, to date, it does not. Therefore, IT IS UP TO YOU to stop services beforehand. Thanks. I remember one of the Cygwin major contributors indicating that (s)he didn't find the need to stop the Cygwin services first, but perhaps I misunderstood. I think the following is obvious but to make sure and for those not experience with such issues: Wouldn't we also need to stop all Shells or any other CygWin process? And: If there are not CygWin processes (services, shells, other apps) is it considered a bug if Setup cannot complete the update? A related but really different question: I had to use source to compile a module with different from default options. How can that module be installed so that Setup will STOP trying to replace it? (...and thus not need me to uncheck the item, or ensure it is unchecked, on each run of Setup. Is this procedure described somewhere (FAQ etc.)? -- Herb Martin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: SETUP: In-use files have been replaced
Herb Martin wrote: Wouldn't we also need to stop all Shells or any other CygWin process? Yes, of course. And: If there are not CygWin processes (services, shells, other apps) is it considered a bug if Setup cannot complete the update? What do you mean cannot complete the update? Setup should always be able to perform the updates, but if files are in use it will have to schedule them to be replaced on the next reboot. There is nothing it can do about this as it's a restriction of the windows filesystem. I had to use source to compile a module with different from default options. How can that module be installed so that Setup will STOP trying to replace it? Don't use the same location as the packaged version. (...and thus not need me to uncheck the item, or ensure it is unchecked, on each run of Setup. If you replace a packaged file with one of your own, you will almost certainly encounter problems at some later point. All package management systems work this way, which is why you must use the designated locations (/usr/local, /opt, etc.) or otherwise inform the package system of your desire (for example, debian/apt has diversions.) You will have the same thing happen on a linux system if you replace a file in /usr/lib with a self-compiled one. Brian -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
RE: SETUP: In-use files have been replaced
-Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Brian Dessent Sent: Tuesday, October 18, 2005 5:48 PM To: cygwin@cygwin.com Subject: Re: SETUP: In-use files have been replaced Herb Martin wrote: Wouldn't we also need to stop all Shells or any other CygWin process? Yes, of course. And: If there are not CygWin processes (services, shells, other apps) is it considered a bug if Setup cannot complete the update? What do you mean cannot complete the update? Setup should always be able to perform the updates, but if files are in use it will have to schedule them to be replaced on the next reboot. There is nothing it can do about this as it's a restriction of the windows filesystem. The context of the discussion was in use files requiring a reboot to complete the update so (obviously) I mean: Would it be considered a bug if all CygWin services, shells, and apps are shutdown but a reboot is still required by Setup? I had to use source to compile a module with different from default options. How can that module be installed so that Setup will STOP trying to replace it? Don't use the same location as the packaged version. Oddly enough, I didn't do that (for accidental reasons) and suspected that my mistake was in NOT using the download location. (...and thus not need me to uncheck the item, or ensure it is unchecked, on each run of Setup. If you replace a packaged file with one of your own, you will almost certainly encounter problems at some later point. All package management systems work this way, which is why you must use the designated locations (/usr/local, /opt, etc.) or otherwise inform the package system of your desire (for example, debian/apt has diversions.) You will have the same thing happen on a linux system if you replace a file in /usr/lib with a self-compiled one. So what is the method to teach Setup that the file has been updated. The versions are the same LEVEL/source, but my version has been specially (switches/settings) make compiled. -- Herb Martin -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
