This is probably "grounds" for a send-pr, but I thought I'd better check
here first to see if it's either already known or maybe even fixed.

I have my public FTP directory NFS mounted on my other servers, and then
I use a loopback mount to put them squarely in /var/spool/ftp/pub on
each server (so that an anonymous chroot'ed ftp works to any server just
as it does to the official one).

This seems to work fine except when I do a recursive removal of a
directory hierarchy.  Some portion of the tree is correctly removed and
then suddenly "rm" starts reporting "Invalid argument".  Here's an
example:

$ uname -smr
NetBSD 1.4V i386
[[ and the kernel is from a March 22 sup ]]

$ rm -rf ip_fil3.4.4
rm: ip_fil3.4.4/ipft_sn.c: Invalid argument
rm: ip_fil3.4.4/ipft_td.c: Invalid argument
rm: ip_fil3.4.4/ipft_tx.c: Invalid argument
rm: ip_fil3.4.4/ipl.h: Invalid argument
rm: ip_fil3.4.4/ipmon.c: Invalid argument
^?
$ ls -l ipft_sn.c
-rw-------  1 woods  ftpadmin  4225 Mar 13 17:10 ipft_sn.c
$ id
uid=1000(woods) gid=10(sunstaff) groups=10(sunstaff),0(wheel),5(operator),20(staff),105(ftpadmin)
$ rm ipft_sn.c
$ ls -l ipft_sn.c
ls: ipft_sn.c: No such file or directory

$ /sbin/mount
/dev/sd0a on / type ffs (NFS exported, local)
/dev/sd0e on /var type ffs (NFS exported, local)
/dev/sd1a on /altroot type ffs (NFS exported, local)
/dev/sd4h on /backups type ffs (local)
/dev/sd1e on /tmp type ffs (NFS exported, local)
/dev/sd0f on /cvs type ffs (local)
/dev/sd1f on /opt type ffs (NFS exported, local)
/dev/sd2h on /work type ffs (NFS exported, local)
most.weird.com:/big1 on /most/big1 type nfs
most.weird.com:/netbsd-1.4 on /most/netbsd-1.4 type nfs
most.weird.com:/spare on /most/spare type nfs
most.weird.com:/var on /most/var type nfs
kernfs on /kern type kernfs (local)
procfs on /proc type procfs (local)
fdesc on /fdesc type fdesc (local)
/most/var/spool/ftp/pub on /var/spool/ftp/pub type null

$ /bin/pwd
/var/spool/ftp/pub/mirror


Is there anything further I can do to debug this if indeed I should be
sending a PR to note it officially?  I can ktrace rm if that will help
(it would obviously help to determine the exact number of successful
unlink()s before the failures begin).

-- 
							Greg A. Woods

+1 416 218-0098      VE3TCP      <gwoods@acm.org>      <robohack!woods>
Planix, Inc. <woods@planix.com>; Secrets of the Weird <woods@weird.com>