29 Dec
2021
29 Dec
'21
7:13 p.m.
what was the last Unix version
that let users make arbitrary links, such that the file system was no
longer a DAG? I recall in v6 days hearing that earlier Unix allowed
this, and that cleanup (via icheck and friends) got to be near
impossible.
From v1 on (I'm not sure about PDP-7 Unix) only
the superuser could do
that, so what you heard strikes me as urban legend. Perhaps
some
installations abused root privilege to scramble the file system, but I
certainly didn't see that happen in Research systems.
Doug
29 Dec
29 Dec
7:37 p.m.
New subject: moving directories in svr2
On Wed, Dec 29, 2021 at 2:14 PM Douglas McIlroy
<douglas.mcilroy(a)dartmouth.edu> wrote:
I recall doing this on some system via a lesser-known flag to `ln`.
But I believe that a) you had to be root, and b) fsck sure was unhappy
after the fact. I gather it was one of those, "wizard sysadmin invokes
the deep magic from single user mode to fix the filesystem" and like
other such arcana was mostly for dealing with seriously perverse
failure modes, possibly in concert with the `unlink` command.
https://www.freebsd.org/cgi/man.cgi?query=ln&apropos=0&sektion=0&am…
says that the `-f` flag to `ln` would force a hard link to a directory
on (at least) SunOS 4.1.3.
The 4.3BSD man page has this gem: "Hard links may not refer to
directories (unless the proper incantations are supplied) and may not
span file systems." And indeed, a quick look at /usr/src/bin/ln.c on a
VAX running 4.3 shows that it has an undocumented `-f` flag:
presumably the "proper incantation" mentioned in the man page.
- Dan C.
what was the
last Unix version
that let users make arbitrary links, such that the file system was no
longer a DAG? I recall in v6 days hearing that earlier Unix allowed
this, and that cleanup (via icheck and friends) got to be near
impossible.
From v1 on (I'm not sure about PDP-7 Unix) only the superuser could do
that, so what you heard strikes me as urban legend. Perhaps some
installations abused root privilege to scramble the file system, but I
certainly didn't see that happen in Research systems.
8:15 p.m.
New subject: moving directories in svr2
On Wed, Dec 29, 2021 at 2:37 PM Dan Cross <crossd(a)gmail.com> wrote:
The 4.3BSD man page has this gem: "Hard links may
not refer to
directories (unless the proper incantations are supplied) and may not
span file systems." And indeed, a quick look at /usr/src/bin/ln.c on a
VAX running 4.3 shows that it has an undocumented `-f` flag:
presumably the "proper incantation" mentioned in the man page.
On a lark, I decided to check for this on 7th Edition as well. The man
page says, quite clearly: "It is forbidden to link to a directory or
to link across file systems." However, /usr/src/cmd/ln.c has the
undocumented `-f` flag, and if given, will elide checking for whether
the "name1" argument is a directory or not. Looking at the kernel, as
Doug mentioned, one must be the superuser to link a directory.
- Dan C.
8:42 p.m.
New subject: moving directories in svr2
https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with:
Each directory always has at least two entries. The
name "." in each directory refers to the directory itself. Thus a
program may read the current directory under the name “.”
without knowing its complete path name. The name “..” by
convention refers to the parent of the directory in which it
appears, that is, to the directory in which it was created.
The directory structure is constrained to have the form
of a rooted tree. Except for the special entries “.” and “..”,
each directory must appear as an entry in exactly one other,
which is its parent. The reason for this is to simplify the
writing of programs which visit subtrees of the directory
structure, and more important, to avoid the separation of
portions of the hierarchy. If arbitrary links to directories
were permitted, it would be quite difficult to detect when
the last connection from the root to a directory was severed
8:58 p.m.
New subject: moving directories in svr2
Partitioning the tree sure seems like it would lead to a bad day, doesn't it?
I expect the undocumented arcana related to linking directories was
always an escape hatch for a skilled administrator to rescue a sick
system. One can imagine any number of ways in which directory files
could be corrupted; sufficient inspection of disk contents might give
someone with the requisite low-level knowledge sufficient information
that they could, say, reattach a pruned subtree with clever uses of
`ln -f` and `unlink`. Did `icheck` and friends have something
analogous to the `lost+found` directory created by `fsck`? I could
imagine (somewhat painfully) executing those commands while in
single-user mode on the console.
- Dan C.
On Wed, Dec 29, 2021 at 3:42 PM Richard Salz <rich.salz(a)gmail.com> wrote:
https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with:
Each directory always has at least two entries. The
name "." in each directory refers to the directory itself. Thus a
program may read the current directory under the name “.”
without knowing its complete path name. The name “..” by
convention refers to the parent of the directory in which it
appears, that is, to the directory in which it was created.
The directory structure is constrained to have the form
of a rooted tree. Except for the special entries “.” and “..”,
each directory must appear as an entry in exactly one other,
which is its parent. The reason for this is to simplify the
writing of programs which visit subtrees of the directory
structure, and more important, to avoid the separation of
portions of the hierarchy. If arbitrary links to directories
were permitted, it would be quite difficult to detect when
the last connection from the root to a directory was severed
9:20 p.m.
New subject: moving directories in svr2
On Wed, Dec 29, 2021 at 3:59 PM Dan Cross <crossd(a)gmail.com> wrote:
Did `icheck` and friends have something analogous to
the `lost+found`
directory created by `fsck`?
The lost+found directory was a tjk-ism although I can get a very small
level of credit/inspiration. It was born of need. Ted was explaining to
me one night that one of the issues when you had identified a file that no
directory was claiming was what to do with it. Originally, Ted linked lost
files into root because there was usually only a couple of files, but ...
we startiong seeing a situation where often the root directory did not have
free directory slots.
Some of the folks (I want to say it was either bio-med or architecture
dept) had a recurring crash that occurred after a bunch of intermediate
files had been created on a long running program. If the program stopped
we had a way of restarting it part way using them. The problem was that
people did not clean up the /tmp directory so the program unlinked them
after creating them. But if it crashed, the files were still there but
just connected to anything. Ted could find them with f*ck [it had a
different name then].
I remember that we talked more about the issue and he came up with the idea
of creating the directory lost+found and then preallocating a bunch of
slots with a shell script instead of hoping the root directory was going to
being available.
30 Dec
30 Dec
3:15 a.m.
New subject: moving directories in svr2
On Dec 29, 2021, at 12:42 PM, Richard Salz
<rich.salz(a)gmail.com> wrote:
https://dsf.berkeley.edu/cs262/unix.pdf section 3.2 ends with:
Each directory always has at least two entries. The
name "." in each directory refers to the directory itself. Thus a
program may read the current directory under the name “.”
without knowing its complete path name. The name “..” by
convention refers to the parent of the directory in which it
appears, that is, to the directory in which it was created.
The directory structure is constrained to have the form
of a rooted tree. Except for the special entries “.” and “..”,
Note that "." or ".." entries are not needed if you store the
entire path of the current working dir. in a process'es kernel
state. My guess is *not* storing a path instead of a ptr to
the inode was done to save on memory.
each directory must appear as an entry in exactly one
other,
which is its parent. The reason for this is to simplify the
writing of programs which visit subtrees of the directory
structure, and more important, to avoid the separation of
portions of the hierarchy. If arbitrary links to directories
were permitted, it would be quite difficult to detect when
the last connection from the root to a directory was severed
Every inode has a linkcount so detecting when the last conn.
is severed not a problem. The separation *can* occur in any
case if the system crashes at the wrong time and you can
find #inode-number named directories in /lost+found.
plan9 folks finessed the problem by not storing the linkcount.
This is why moving a tree is a copy and then rm -rf of the old
location. You win some, you lose some.
Clem wrote:
Late binding to names (like symlinks) are a dynamic
(runtime idea). Bakul points out that by using the per process u area, the dynamic
context can be retained. The observation is that .. (like symlinks) tend to be a runtime
(dynamic) notion, although I'm not sure how you keep consistency in the static FS if
you don't store the link in the inode.
Symlinks are not a runtime idea but $PWD is strictly a runtime
thing. With symlinks perhaps 4.xBSD took the easy way out by
decreeing that only 8(?) symlink may be traversed at runtime
in interpreting a path for open etc, perhaps to save space but
detecting loops can be done by storing <fsid,inum> per component
and checking that. The same algorithm would help if multiple dir.
hard links were allowed. Sure it has O(n) behavior but the user
pays for it, or you can put a liberal limit on this array.
I don't have much experience with crash recovery on plan9 so
don't know if not having linkcounts is a problem. I haven't
thought through about whether there are crash or concurrency
related issues with allowin arbitray graphs by dir linking.
But probably fixable by writing an intent log ala DBMS.
At the risk of kicking a dead horse too much
I think it helps to once in a while wonder about why/how some
system decisions were made and learn something from that; or
gain a deeper understanding. At least that is my excuse!
Thanks for all the responses. My take away is that while it
is possible to allow arbitrary dir links, it would increase
implementation complexity while the added benefit of it are
few if any.
940
days inactive
941
days old
6 comments
5 participants
participants (5)
-
Bakul Shah -
Clem Cole -
Dan Cross -
Douglas McIlroy -
Richard Salz