Re: patch for fs/dcache race

Albert D. Cahalan (acahalan@cs.uml.edu)
Tue, 12 Aug 1997 22:10:13 -0400 (EDT)


>> There are only two characters not legal in a file name
>> in Unix, '\0' and '/'.

Well actually... at the Open Group web site the Single Unix
Specification version 2 seems to indicate otherwise.
Portable filenames are [A-Za-z0-9_.][A-Za-z0-9_.-]*
Enforcing that fixes the "-rf /" file in /tmp problem. :-)

>> Perhaps some simple scheme like doubling the
>> slash before deleted names would be less ambiguous?

>> /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.

That works great.

What about this though: ../foo/bar/baz
It matches up too if you mount procfs on /proc.

[about multiple slashes again]

> It breaks POSIX, and a helluva lot of tools. Unix has
> the "multiple slash rule", which says that multiple slashes
> are treated as one (in fact, traditional Unices treat // as /./)
> and a final slash like a final slash-dot.

No way, this is not in normal filenames. This is the content
of a magic symlink in /proc. It used to read like [0307]:1097,
which didn't break POSIX either since /proc is not a normal
filesystem and it has nothing to do with POSIX.

If anything, the POSIX rule makes this _better_ because the
names mean the same thing to POSIX applications. Special Linux
tools will know what it means and POSIX applications won't care.
(Wait, does POSIX even have symlinks? If not, anything goes!)

Another good way is to skip the leading slash. You end up with
a "broken" symlink, which is the most correct meaning. This
may be the best way since normal apps won't think the files
are the same thing.

/foo/bar/baz normal
../foo/bar/baz deleted, method 1
/foo/bar//baz deleted, method 2
foo/bar/baz deleted, method 3

Method 2 might let the kernel indicate deleted directories.
(you CAN delete them because the filenames are gone)