Wow. Ambitious! On Tue, Feb 05, 2013 at 03:24:48PM +0000, Jon TURNEY wrote: >I find it irritating to have to work out which process I need to stop when >setup >can't update a file, and setup not helping you find it doesn't really meet >contemporary standards. So, loosely inspired by [1], a patch to list and >offer >to kill processes preventing a file from being written. > >This uses psapi.dll to find which out processes have a file loaded as a module. > >Note that this doesn't help when file isn't writeable because process has the >file open exclusively, but there doesn't seem to be an interface to do this >until the restart manager API introduced in Vista. > >This relies on the probably undocumented behaviour of /usr/bin/kill working >with >windows PIDs as well as cygwin PIDs, and the assumption those PID sets are >disjoint.
Why not just use TerminateProcess rather than Cygwin's /usr/bin/kill? FWIW, Cygwin's pids often == Windows pids. They are derived from the same pool. I really like this idea but I wonder if the use of psapi.dll will mean that setup-legacy.exe will be broken by that change since it is supposed to work on older platforms. And, I wonder if it really is time to stop offering the old 1.5.x binaries so we wouldn't have to worry about that. Other than that, I see some very minor formatting problems - you need to put spaces before opening parentheses for functions and macros. >Ideally, I wanted to note if the process which had the file loaded was a >service, and stop and restart the service. But this seems to be not >straightforward to do, as setup doesn't have any visibility of the cygwin >process tree, which is needed to find the cygrunsrv service process which is >the >parent of the process using the file, and thus the service name to stop and >restart. Is there any way to determine if a process is running as a service? If so, I'd think that just telling someone they had to restart the service would be adequate. cgf