On Feb 8 13:16, Andrew Schulman wrote: > > On Feb 8 12:22, Andrew Schulman wrote: > > > $ cygpath -u 'C:\WINDOWS' > > > /win/c/WINDOWS > > > > > > $ cygpath -pu 'C:\WINDOWS' > > > 15 [main] cygpath 5076 C:\cygwin\bin\cygpath.exe: *** fatal error - > > > wide char path lists not > > > yet supported > > > Hangup > > > > Try `uname -r' > > Erf, thanks. I had updated to 1.7.10, but as you guessed, uname -r said > 1.7.9. > > BTW, after restarting all Cygwin process, uname -r still said 1.7.9. So I > rebooted; still 1.7.9. So > I looked in c:\cygwin\bin, and found that cygwin1.dll was still version > 1.7.9, but there was also > cygwin1.dll.new, version 1.7.10. So I removed cygwin1.dll and renamed > cygwin1.dll.new, and now I'm > running 1.7.10. > > Is that the expected behavior for setup? I assume that I had left some > Cygwin processes running > when I updated to 1.7.10. I don't remember setup warning me about replacing > files in use, although > maybe it did and I forgot. But I thought the problem was supposed to take > care of itself after a > reboot - I don't remember ever encountering cygwin1.dll.new before.
THe fact that you have a .new file shows that setup tried to replace the file after reboot. However, the Win32 functionality, MoveFileEx with MOVEFILE_DELAY_UNTIL_REBOOT | MOVEFILE_REPLACE_EXISTING flags apparently doesn't work under all circumstances. See, for instance, http://social.msdn.microsoft.com/Search/en-US?query=PendingFileRenameOperations for more information. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
