Re: patch for fs/dcache race

Linus Torvalds (torvalds@transmeta.com)
Tue, 12 Aug 1997 14:41:07 -0700 (PDT)


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