[8851] in Athena Bugs
AFS cache confusion with linked files
daemon@ATHENA.MIT.EDU (John Carr)
Sun Jan 19 14:45:02 1992
To: bug-afs@Athena.MIT.EDU
Cc: bugs@Athena.MIT.EDU
Date: Sun, 19 Jan 92 14:44:47 EST
From: John Carr <jfc@Athena.MIT.EDU>
Renaming a file over a file with multiple links results in the other
links to that file having the wrong link count. Reading the file
sometimes corrects the link count. Example:
/afs/athena.mit.edu/user/j/jfc/nb/tmp > ls file?
-rw-r--r-- 2 jfc 14656 Nov 2 20:03 file1
-rw-r--r-- 2 jfc 14656 Nov 2 20:03 file2
-rw-r--r-- 1 jfc 14656 Jan 19 14:32 file3
/afs/athena.mit.edu/user/j/jfc/nb/tmp > mv file3 file1
/afs/athena.mit.edu/user/j/jfc/nb/tmp > ls file?
-rw-r--r-- 1 jfc 14656 Jan 19 14:32 file1
-rw-r--r-- 0 jfc 14656 Nov 2 20:03 file2
/afs/athena.mit.edu/user/j/jfc/nb/tmp > cp file2 /dev/null
/afs/athena.mit.edu/user/j/jfc/nb/tmp > ls file?
-rw-r--r-- 1 jfc 14656 Jan 19 14:32 file1
-rw-r--r-- 1 jfc 14656 Nov 2 20:03 file2
The equivalent commands with using a file with 3 links results in 2
references to the same file, both with a link count of 1. In this case
reading the file is not sufficient to fix the link count. One time I tried
this the contents of the file were apparently lost: only the first character
of the file could be read on the workstation I was doing my tests on. I was
able to read the file on another workstation, and writing the file there
caused the new copy with the correct link count to appear on the confused
client too.
I have seen this on an RT (Achates, which has some changes to the AFS code
that should not affect this bug) and an RS/6000 (tardis).
