From: Nikolaus R. <Nik...@ra...> - 2011-12-05 22:21:55
|
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. Best, -Nikolaus -- »Time flies like an arrow, fruit flies like a Banana.« PGP fingerprint: 5B93 61F8 4EA2 E279 ABF6 02CF A9AD B7F8 AE4E 425C |