From: Goswin v. B. <gos...@we...> - 2011-12-06 08:10:00
|
Nikolaus Rath <Nik...@ra...> writes: > Goswin von Brederlow <goswin-v-b-S0/GAf...@pu...> writes: >> Nikolaus Rath <Nik...@pu...> writes: >> >>> @@ -307,6 +323,11 @@ >>> >>> /** >>> * Remove a file >>> + * >>> + * If the file's inode's lookup count is non-zero, the file >>> + * system is expected to postpone any removal of the inode >>> + * until the lookup count reaches zero (see description of the >>> + * forget function). >>> * >>> * Valid replies: >>> * fuse_reply_err >> >> Are you sure about that? >> >> If I properly use inode generation numbers and set and use fi->fh in all >> callbacks having "struct fuse_file_info *fi" then what stops me from >> removing and even reusing an inode that is still opened let alone looked >> up. > > Your file system may still receive e.g. a readlink() request for an > inode after the call to unlink. You can't answer that unless you have > postponed the removal. > > Of course, you could reply with ENOENT, but I think the very fact that > your file system receives the request shows that the kernel expects it > to still have the inode ready. Having recieved a unlink request for the inode any lookup, getattr (without fi->fh) or open request returns ENOENT. Why should readlink() be special? Note: There is fstat() so getattr with fi->fh set has to work on deleted inodes but there is no freadlink(). I think the only way to get the kernel to send a readlink() would be a race condition where one process calls readlink() while another calls unlink() at the same time. ENOENT is what I (as application) expect to recieve on readlink of a deleted file and other filesystems do behave that way. MfG Goswin |