31 Dec
2021
31 Dec
'21
7 a.m.
Grumpy hat on.
Sometimes the Unix community suffers from the twin attitudes of a)
believing if it can't be done perfectly, any improvement shouldn't be
attempted at all and b) it's already done as well as is possible anyway.
I disagree with both of these positions, obviously, but have given up
pushing against them.
We're in the 6th decade of Unix and we still suffer from unintended,
fixable consequences of decisions made long long ago.
Grumpy hat off.
-rob
On Fri, Dec 31, 2021 at 11:44 AM Bakul Shah <bakul(a)iitbombay.org> wrote:
On Dec 30, 2021, at 2:31 PM, Dan Cross
<crossd(a)gmail.com> wrote:
On Thu, Dec 30, 2021 at 11:41 AM Theodore Ts'o <tytso(a)mit.edu> wrote:
Without the ".." entry you can't map a dir inode back to a path.
Note that something similar can happen even today:
$ mkdir ~/a; cd ~/a; rm -rf ~/a; cd ..
cd: no such file or directory: ..
$ mkdir -p ~/a/b; ln -s ~/a/b b; cd b; mv ~/a/b ~/a/c; cd ../b
ls: ../b: No such file or directory
You can't protect the user from every such case. Storing a path
instead of the cwd inode simply changes the symptoms.
The other problem with storing the path as a string is that if
higher-level directories get renamed, the path would become
invalidated. If you store the cwd as "/foo/bar/baz/quux", and someone
renames "/foo/bar" to "/foo/sadness" the cwd-stored-as-a-string
would
become invalidated.
Why? Presumably as you traversed the filesystem, you'd cache, (path
component, inode) pairs and keep a ref on the inode. For any given
file, including $CWD, you'd know it's pathname from the root as you
accessed it, but if it got renamed, it wouldn't matter because you'd
have cached a reference to the inode.