[551] in Athena Bugs
re: A bug with "ls" in 6.0B VAX
daemon@ATHENA.MIT.EDU (John Carr)
Fri Jul 22 23:09:36 1988
To: bugs@ATHENA.MIT.EDU
Cc: vanharen@ATHENA.MIT.EDU
Date: Fri, 22 Jul 88 23:07:51 EDT
From: John Carr <jfc@ATHENA.MIT.EDU>
I've seen this problem before (5.5). It seems that when a file is
truncated by quota, its length may be listed as the number of bytes
sent to the fileserver rather than the number of bytes sucessfully
written. Here's a way to reproduce an inconsistency (I am ~130 K
below my hard limit):
% cp `where emacs` . &
[8] 11765
% stat emacs
File: "emacs"
Size: 139264 Allocated Blocks: 248 Filetype: Regular File
[other stuff deleted]
% ls -l emacs
-rwxr-x--t 1 jfc 401408 Jul 22 22:54 emacs
% stat emacs
Size: 630784 Allocated Blocks: 248 Filetype: Regular File
% ls -l emacs
-rwxr-x--t 1 jfc 786432 Jul 22 22:54 emacs
% stat emacs
Size: 1155072 Allocated Blocks: 248 Filetype: Regular File
% ls -l emacs
-rwxr-x--t 1 jfc 1392640 Jul 22 22:54 emacs
% stat emacs
DISK LIMIT REACHED (host poseidon.MIT.EDU) - WRITE FAILED
Size: 131072 Allocated Blocks: 248 Filetype: Regular File
% ls -l emacs
-rwxr-x--t 1 jfc 393216 Jul 22 22:55 emacs
% stat emacs
Size: 122880 Allocated Blocks: 248 Filetype: Regular File
[8] Done cp `where emacs` .
% ls -l emacs
-rwxr-x--t 1 jfc 122880 Jul 22 22:55 emacs
It can be done with core dumps, too:
% kill -3 %scribe
[8] Quit scribe (core dumped)
% ls -l core
-rw-r--r-- 1 jfc 163840 Jul 22 23:01 core
% quota -v
Filesystem usage quota limit timeleft files quota limit timeleft
/mit/jfc 716 600 720 7.0 days 241 300 360
% "rm" core
% quota -v
Filesystem usage quota limit timeleft files quota limit timeleft
/mit/jfc 592 600 720 240 300 360
The difference is less than 163 K. I would guess that the fileserver adds to
the length of a file before it checks to see if the write fails.
