Linus wrote, among other immodest boasting:
> I'm not only exceedingly clever, I'm also a conceited little bugger,
> ain't I?
Yay! Cheers! Hurrah!
It's attitudes like this that make Linux exceedingly fun to play with.
I remember when Dave Miller got cross-machine TCP/IP to run faster
that Sun's libc memcpy(). Bragging rights.
I remember when Linus introduced the "I've got too much money" license.
Good attitude. Fuck 'em if they can't take a joke.
Thank you all for keeping things fun.
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?
Second, do you want the name to be uniquely parseable?
It's legal to have a file named "foo (deleted)".
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?
E.g.
/foo//bar//baz
Means that "bar" and "baz" are deleted, but not "foo".
Compare with /foo/bar//baz, where nothing has happened to the
parent directory.
Or is that overloading too heavily used anyway? Or doesn't anyone care
if it's ambiguous?
-- -Colin