I'm not familiar with the dcache mechanics, and I would guess that you
are correct (that it can't be made to work) but to help us users
understand the reasons,
1. What problems would happen when renaming "Foo" to "foO" that would
not be open when renaming "Foo" to "baR"? On any rename, compliant
programs should expect the file name to disappear indefinitely (and
another name to appear) so it shouldn't matter if it is not available
from the directory for a few cycles.
2. What semantics would be broken by renaming "Foo" to "foO" that would
not be broken by renaming "Foo" to "unreadable_directory/uniqueXYZ0001"
and then back to "foO"? I'm not saying this is the implementation,
just a semantics question.
If we view the rename as a rename to a different name, we expect all the
references to the existing code to break. Any program that is prepared
for two consecutive renames should be able to handle the semantics, if
we choose semantics that are in line with #2 above. This is what the
user will do anyway if they are doing this by hand, so if we make it
automatic, then programs will not have to handle "rename works, but
it depends on the name".
As for DOS semantics, it would be helpful to me (for something else
I am working on) to know if there are same-name issues.
Kevin
-----kbealier.at.stny.lrun.com-------------------------------------
THE LESSER-KNOWN PROGRAMMING LANGUAGES #12: LITHP
This otherwise unremarkable language is distinguished by the
absence of an "S" in its character set; users must substitute
"TH". LITHP is said to be useful in protheththing lithtth.
-
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/