Re: smbfs: "rm -rf" dircache problems
Petr Vandrovec Ing. VTEI (VANDROVE@vc.cvut.cz)
Thu, 11 Nov 1999 19:05:18 MET-1
On 11 Nov 99 at 00:45, Michael Nelson wrote:
> I noticed this weekend that "rm -rf" doesn't work very well on SMBFS
> because as its dircache gets repopulated, a whole bunch of entries are
> skipped which happen to now be below filp->f_pos.
> A cursory glance at the NFS and NCPFS file systems seems to show that the
> former doesn't have this problem, but NCPFS may.
Hi Michael,
we had this problems with ncpfs, but we hope that it is fixed now (in 2.3
tree). We now build complete dentries and inodes not only in lookup, but in
readdir too (we can do this as NCP directory scan function can return
all important inode data). We set dentry's d_fsdata to position in directory
and as this field is revalidated only if directory is reread, it will
work for 'rm -rf' too (it is NOT revalidated/invalidated on unlink/rmdir).
There are two open problems now (probably never fixed):
1) if you remove 'current' readdir entry by unlink, netware then refuses
your 'current' position and returns 'end of directory' (rm prematurely
stops). It is not problem with glibc (2.1), as it always overestimates
buffer size (i.e. it has to seek back on next getdents call) and never
returns last entry to caller program. It could be problem with libc5, but
I never saw this without using specific tools written just for
exploiting it.
2) if you do 'rm -f dir' together with 'while true; do ls dir; done',
'ls' can (and will) cause renumbering of directory entries.
Best regards,
Petr Vandrovec
vandrove@vc.cvut.cz
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/