This is the mail archive of the
mailing list for the Cygwin project.
Re: rm fails but returns success
Corinna Vinschen skrev 2012-02-03 17:37:
> On Feb 3 17:27, Peter Rosin wrote:
>> Corinna Vinschen skrev 2012-02-03 17:17:
>>> On Feb 3 17:02, Peter Rosin wrote:
>>>> I have this annoying leftover file from a automake testsuite run.
>>>> I don't know if it was created by an MSYS process or a Cygwin
>>>> process, but I can't get rid of it. I can't take ownership of
>>>> it either, not even as admin. I haven't tried stopping all
>>>> MSYS/Cygwin processes yet, nor rebooting, but I'd rather not.
>>>> Any help with that is appreciated. No, not rebooting :-)
>>>> However, that is not really why I'm writing, I'm writing to
>>>> report the following bug related to the above file.
>>>> $ uname -a
>>>> CYGWIN_NT-6.1-WOW64 peda-pc 1.7.10s(0.259/5/3) 20120123 00:15:09 i686 Cygwin
>>>> $ ls -l aclibobj.log-t
>>>> -rw-r----- 1 ???????? ???????? 2113 Jan 31 16:09 aclibobj.log-t
>>>> $ rm aclibobj.log-t; echo $?
>>>> rm: remove write-protected regular file `aclibobj.log-t'? yes
>>> Send an strace of this, please. One reason that rm (better: unlink(2))
>>> reports success is if the file is still in use by another process but
>>> it's already marked as "delete pending" in the OS. This should only
>>> occur if a non-Cygwin process is still holding a handle to the file.
>> Here's the strace.
>> 17 11885 [main] rm 16748 unlink_nt: Trying to delete \??\C:\cygwin\home\peda\automake\tests\aclibobj.log-t, isdir = 0
>> 26 11911 [main] rm 16748 unlink_nt: Delete \??\C:\cygwin\home\peda\automake\tests\aclibobj.log-t already pending
>> 16 11927 [main] rm 16748 unlink_nt: \??\C:\cygwin\home\peda\automake\tests\aclibobj.log-t, return status = 0x0
>> 15 11942 [main] rm 16748 unlink: 0 = unlink(/home/peda/automake/tests/aclibobj.log-t)
> Yup, as I supected. The delete is pending already. Therefore the file
> is logically already successfully deleted. Only the fact that some
> importunate non-Cygwin process is still holding an open handle to the
> file forestalls its disappearance.
> There's nothing at all you can do about that, other than to identify the
> process holding the open handle and kill it.
I killed the suspended MSYS expr process that I mentioned in the other
mail (I also confirmed that it indeed had the file open) and the file
Thanks for your help!
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple