Dave Korn writes: > Err, that should never happen, unless you're updating from a > several-years-old DLL. The Cygwin DLL is intended to be backwardly > compatible, and only rarely have their been ABI breaks. So this aspect of > updating doesn't get tested very often. > Yes, I was testing an upgrade from a couple year old version: 1.5.12
> > I guess the obvious answer is to make sure NO cygwin related processes are > > running when you run setup. But I was hoping it would just schedule the > > files for replacement and do it on the next reboot. > > Well, yeh, it did do that. But there's no mechanism to schedule all the > postinstall scripts to not be run until the next reboot, which IIUIC is what > would be needed here for them not to crash. I think the safest bet for me in this case is to just kill off everything and run setup. Since I'll be doing this upgrade on close to 100 boxes, I've been trying to devise a *relatively* unattended process. In case it helps anyone in the future, here's a snippet of my cmd script I have so far: echo off echo This will kill all cygwin related processes and update cygwin echo Hit CTRL-C now to abort, otherwise: pause c:\cygwin\bin\bash.exe --login -c "ps -la|sed 's/^I/ /'|awk '{print $4}'|grep - v WINPID >/tmp/pids.txt" for /F %i in (c:\cygwin\tmp\pids.txt) DO taskkill /PID %i /F del /F c:\cygwin\tmp\pids.txt echo running setup... \\fileserver\cygwin\setup-2.602.exe -q -L -l \\fileserver\cygwin -R C:\cygwin echo Done -- 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/