Mail Archives: cygwin/2012/02/08/14:47:34
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
- Raw text -