Hello Doug, hello Matthew, hello list members,
there are some hints that readdir() in -STABLE has problems when
used on NFSv3 (UDP; and TCP probably, too) mounted file systems.
The reason may be the recovery code for stale READDIR cookies.
The problem occurs when using GNU rm (fileutils-4.0) on our
systems (NFS servers and clients -STABLE) for deleting large
directory trees (e.g. egcs source tree). rm failed to delete
some directories:
rm: cannot remove directory `egcs-1.1.2/gcc': Directory not empty
I've roughly looked through the sources and found a workaround
for a readdir() bug on SunOS 4.1.4. The SunOS readdir() sometimes
returned NULL although there were still entries to be read when
a directory with more than 254 entries was previously modified.
The workaround rewound the directory stream and read it again.
Interestingly this workaround also works for FreeBSD although
our readdir() passes the autoconfig tests that trigger the
workaround without a hinch.
Attached is a patch for GNU fileutils-4.0 that will make rm
yield when the workaround code catches a bad readdir().
Björn Fischer
PS: Please don't ask me why I'm using GNU fileutils.
--- remove.c 1999/08/29 02:57:38 1.1
+++ remove.c 1999/08/29 03:07:42
@@ -526,6 +526,8 @@
{
/* empty */
}
+ if (dp != NULL)
+ fputs("*** readdir() returned NULL and shouldn't.\n", stderr);
}
#endif
--
-----BEGIN GEEK CODE BLOCK-----
GCS d--(+) s++: a- C+++(-) UB++++OSI++++$ P+++(-) L+++(--) !E W- N+ o>+
K- !w !O !M !V PS++ PE- PGP++ t+++ !5 X++ tv- b+++ D++ G e+ h-- y+
------END GEEK CODE BLOCK------
To Unsubscribe: send mail to majord...@freebsd.org
with "unsubscribe freebsd-hackers" in the body of the message
