Messages in this thread | | | From | "Petr Vandrovec Ing. VTEI" <> | Date | Thu, 11 Nov 1999 19:05:18 MET-1 | Subject | Re: smbfs: "rm -rf" dircache problems |
| |
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/
| |