> Alternately - use the dir entry coordinates but maintain that
> while the inode is open. The cached data should include the
> "new inode number" which is different from the used ino if the
> file was renamed or unlinked while it was open. If an open file
> was deleted/renamed and a new file was created using the same slot,
> a temporary inode number can be allocated for the new file (and
> maintained while this new file is open).
This does the job well:
1. except for rename, inodes on disk are long-term stable
2. inodes are stable for open files, even when renamed
With "open" meaning any process on the system and "inode number"
being what is reported to normal processes, the rules are:
1. Inodes are dir entry coordinates.
2. After rename, inode numbers change as soon as the file is not open.
3. If a new file gets a slot that gives it an inode which conflicts
with the reported inode of an open file, report something else
(really _anything_ else) until both files are no longer open.
Compared to silly_rename this is clean and easy, but it does leave
a larger (infinite vs. milliseconds) window during which a crash
would leave lost clusters.
Oh, no matter what is done here the FAT cache changes seem right.
-
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/