Skip site navigation (1)Skip section navigation (2)
Date:      Sun, 08 Jul 2012 15:41:48 -0700 (PDT)
From:      Andrey Ignatov <rdna@rdna.ru>
To:        FreeBSD-gnats-submit@FreeBSD.org
Cc:        Valery Khromov <qwerty@yandex-team.ru>
Subject:   bin/169723: [patch] find(1) exits with non-zero return code if any file in a directory is deleted while find(1) is traversing the directory
Message-ID:  <4ffa0cac.631d700a.648c.ffffb394@mx.google.com>
Resent-Message-ID: <201207082250.q68Mo7HS062090@freefall.freebsd.org>

next in thread | raw e-mail | index | archive | help

>Number:         169723
>Category:       bin
>Synopsis:       [patch] find(1) exits with non-zero return code if any file in a directory is deleted while find(1) is traversing the directory
>Confidential:   no
>Severity:       non-critical
>Priority:       low
>Responsible:    freebsd-bugs
>State:          open
>Quarter:        
>Keywords:       
>Date-Required:
>Class:          sw-bug
>Submitter-Id:   current-users
>Arrival-Date:   Sun Jul 08 22:50:06 UTC 2012
>Closed-Date:
>Last-Modified:
>Originator:     Andrey Ignatov
>Release:        FreeBSD 10.0-CURRENT amd64
>Organization:
Yandex
>Environment:
System: FreeBSD rdna-s761.yandex.ru 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r228743M: Sat Dec 31 15:15:00 MSK 2011 root@rdna.yandex.ru:/usr/obj/usr/src/sys/RDNA amd64

It seems that the problem appears in find(1) on many versions of FreeBSD
(8-10 at least).

>Description:
find(1) exits with non-zero return code if any file in a directory is deleted
while find(1) is traversing the directory, even though the file is completely
out of find's expression.

For example, we can run:
% find /path/to/some/dir/ -type f -a ! -name '*some_mask*'

Then while find is traversing the directory /path/to/some/dir/ we remove some
files which is out of the expression:
% rm /path/to/some/dir/*some_mask*

(Note: I use "!" in the expression)

After this find finishes with the result like this:
find: /path/to/some/dir/some_mask: No such file or directory
% echo $?
1

>How-To-Repeat:
It's easy to reproduce the problem by using attached Makefile. Just run `make all'.

>Fix:
The patch is in attached freebsd-find-ENOENT-and-removed-files.patch file.

Reported and patched by: Valery Khromov <qwerty@yandex-team.ru>

--- Makefile begins here ---
D:=testdir
FIND?=find

all: prepare
	$(MAKE) -j16 mkfiles rmfiles find

mkfiles:
	dd if=/dev/urandom | hexdump -e '"" 8/1 "%02x" "\n"' | while read i ; do touch "$(D)/$$i"; done

rmfiles:
	while :; do rm -f $(D)/*; sleep 1; done

find:
	while :; do $(FIND) $(D)/ -type f -name '*NAME*' || echo FAILED; done

prepare:
	rm -rf $(D)
	mkdir -p $(D)
--- Makefile ends here ---

--- freebsd-find-ENOENT-and-removed-files.patch begins here ---
Index: /usr/src/usr.bin/find/find.c
===================================================================
--- /usr/src/usr.bin/find/find.c	(revision 228743)
+++ /usr/src/usr.bin/find/find.c	(working copy)
@@ -199,6 +199,8 @@
 		case FTS_DNR:
 		case FTS_ERR:
 		case FTS_NS:
+			if (entry->fts_errno == ENOENT)
+				continue;
 			(void)fflush(stdout);
 			warnx("%s: %s",
 			    entry->fts_path, strerror(entry->fts_errno));
--- freebsd-find-ENOENT-and-removed-files.patch ends here ---


>Release-Note:
>Audit-Trail:
>Unformatted:



Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?4ffa0cac.631d700a.648c.ffffb394>