[10167] in Athena Bugs
file utilities that don't check close()
daemon@ATHENA.MIT.EDU (Calvin Clark)
Thu Dec 31 02:09:25 1992
Date: Thu, 31 Dec 92 02:09:20 -0500
From: Calvin Clark <ckclark@mit.edu>
To: bugs@Athena.MIT.EDU
Reply-To: ckclark@mit.edu
The following is a summary of the behavior of three common file
utilities that often have problems on AFS because they don't check the
return status of close(). This problem can cause users to lose files.
Platform:
sun vax rt decmips rsaix
---------------------------------------
tar broken broken broken broken broken
cp ok ok ok broken broken
mv ok ok ok broken broken
broken: program exits with status 0, does not print error.
>>> mv UNLINKS the source file! <<<
ok: program exits with non-zero status, prints error.
mv does not unlink source file.
Ideally, programs which are often used to manipulate large files should
call fsync() every once in a while, so that over-quota problems can be
detected early on.
I think that it might be good for Athena to provide an "fsync" program
which simply calls fsync() on the file to write it to the server. John
Carr has written such a program, and I have used to demonstate the local
cache/remote file behavior on AFS to confused users: "how come my file
is zero length when I look at it on this machine, but 100K when I look
at it on that machine?" (I believe, for example, that Maple never
closes a file.) It might also be useful in scripts which have to do a
lot of I/O.
-Calvin
