[547] in Athena Bugs
A bug with "ls" in 6.0B VAX
daemon@ATHENA.MIT.EDU (ctest@ATHENA.MIT.EDU)
Fri Jul 22 11:57:12 1988
From: <ctest@ATHENA.MIT.EDU>
To: bugs@ATHENA.MIT.EDU
Reply-To: vanharen@ATHENA.MIT.EDU
Date: Fri, 22 Jul 88 11:56:13 EDT
I noticed a discrepancy between "ls -l" and "ls -s" while scribing a very
large file today...
While scribing a very large (204K) file, I hit the hard limit of this
account. There was about 96K free before starting the scribe run. During
the Scribe run, "ls -l" reported that the file reached (at last check)
229376 bytes, but "ls -s" reports the file as 96K:
% ls -ls
96 -rw------- 1 ctest 229376 Jul 22 11:39 words.lpt
watching "tail -f" showed that the file did not actually continue to grow
past the 96K free. After the scribe run ended:
% ls -ls
96 -rw------- 1 ctest 94208 Jul 22 11:39 words.lpt
Why the difference before and after? Why did "ls -s" show up as 96K the
whole time? Perhaps this isn't a bug -- maybe I just don't understand the
code behind "ls", or perhaps this has something to do with NFS...
Another semi-related question: This was done with Scribe 5, which gave no
I/O error when the quota hard-limit was reached. Will Scribe 6 give an
error if it cannot write out the file?
-Chris VanHaren
