Messages in this thread | | | Date | Tue, 12 Aug 1997 14:41:07 -0700 (PDT) | From | Linus Torvalds <> | Subject | Re: patch for fs/dcache race |
| |
On Tue, 12 Aug 1997, Colin Plumb wrote: > > Now, regarding the dcache: > As Linux wrote: > > [2.1.49] displays a "(deleted)" after the filename if the file is deleted > > (so you know that the name is really only a "hint" - but it does tell you on > > which filesystem the file is open, for example, which is valid information > > worth getting. Think "fuser") > > I was thinking that there are two ambiguities in there: > > First, what if a directory is deleted, not the file. > /foo/bar/baz, and /foo/bar got deleted?
I thought of that, but it's not an issue. You can't delete a directory unless it's empty.
> Second, do you want the name to be uniquely parseable? > It's legal to have a file named "foo (deleted)".
Indeed. This was my major worry about the patch.
> There are only two characters not legal in a file name in Unix, > '\0' and '/'. Perhaps some simple scheme like doubling the > slash before deleted names would be less ambiguous?
My original scheme was to just put '<>' around the name, because all names have to start with a '/' (within this context), so anything of the form '</this/is/a/file>' would show itself to be uniquely deleted.
> /foo//bar//baz
This suggestion would also work.
HOWEVER, in the end I decided that this doesn't make any difference. The "(deleted)" at the end is more human-readable, and as the name is really only for readability anyway. If you want to do machine-readability, it's a lot easier to do a "stat()" on the file and look at the i_nlink value (zero means it's deleted).
So I did something that was (a) easy to implement, and (b) was the most readable I could come up with.
Linus
| |