Date: Mon, 11 Nov 1991 15:53:55 +0200
From: Linus Benedict Torvalds <torvalds@cc.helsinki.fi>
gets symbolic links. I think the easiest way is to move downwards from
the "to"-directory via ".." until one hits root (or a mount-point) or
the "from"-directory. It shouldn't be hard, it's just SMOP.
Well, the problem is that another rename() could be happening while you are
traversing up the tree (towards the root) checking to see if you hit the
"from" directory. The simplest case where you will have a problem is if
rename(/a/b, /a/c/d) and rename(a/c, a/b/e) are running in parallel.
Another problem is that two rename()'s could try to move the same
directory to two different places. Now, locking takes care of this
quite nicely, but the interesting CS question is how little locking can
you do and still be make things be "correct." Or, is there some way
that we can finesse the issue without using locks?
tytso@ATHENA.MIT.EDU (Theodore Ts'o):
> Speaking of hard disk corruptions, I've found an easy way to get Linux
> to corrupt the hard disk. Simply follow the following instructions:
Happily, things aren't that bad (I think). I don't think it's a
buffer-cache problem (which is hell to find - lots of race conditions
etc. I kno - I had those kinds too), but a problem with handling "out
of disk space". That's still bad, but easier to spot. Could you
(tytso) check if the partition filled up? It's probably a bug in one of
tha namei.c-routines which want a new block, and crap out if they cannot
get it. I'll look.
No, my partition didn't fill. Originally I tried it with a partition
size of 65535, so I had lots of free space. I then tried it with "mkfs
/dev/hd3 32768"; the problem still happened. The second time, I noticed
the following things:
* /etc/fsck reported that the disk was completely happy before I ran
"compress -d < /tmp/gcc.tar.Z | tar xvf -"
* During the untaring process, there was at least one time w...
