It looks like this failure can be triggered only via a race condition,
so there's no test case. But I did trigger it via errno == ENOENT,
manually, via gdb.
Hmm... maybe systemtap can help with this.
All I need to do is pause between the opendirat and following unlinkat
attempt long enough to intervene and remove the about-to-be-unlinked file.
2006-10-03 Jim Meyering <[EMAIL PROTECTED]>
* src/remove.c (remove_entry): With -f, exit successfully in spite
of a missing file under some very unusual conditions (with errno
being any of ENOENT, ENOTDIR, ENAMETOOLONG).
Index: src/remove.c
===================================================================
RCS file: /fetish/cu/src/remove.c,v
retrieving revision 1.163
diff -u -r1.163 remove.c
--- src/remove.c 3 Oct 2006 13:13:09 -0000 1.163
+++ src/remove.c 3 Oct 2006 10:36:52 -0000
@@ -1016,6 +1016,9 @@
|| errno == ENOENT || errno == ENOTDIR
|| errno == ELOOP || errno == ENAMETOOLONG)
{
+ if (ignorable_missing (x, errno))
+ return RM_OK;
+
/* Either --recursive is not in effect, or the file cannot be a
directory. Report the unlink problem and fail. */
error (0, errno, _("cannot remove %s"),
_______________________________________________
Bug-coreutils mailing list
[email protected]
http://lists.gnu.org/mailman/listinfo/bug-coreutils
