Path: utzoo!attcan!uunet!wuarchive!usc!apple!portal!cup.portal.com!ts
From: ts@cup.portal.com (Tim W Smith)
Newsgroups: comp.unix.internals
Subject: Re: Trojan Horses
Message-ID: <35111@cup.portal.com>
Date: 21 Oct 90 15:27:57 GMT
References: <BZS.90Oct6191703@world.std.com>
  <BZS.90Oct17215707@world.std.com> <1990Oct18.121818.9956@athena.mit.edu>
Organization: The Portal System (TM)
Lines: 24

<   Programmers failing to check the return value of close() in their programs
< is one of the never-ending problems we have had here at Project Athena.
< 
<   If you are working on a remote filesystem (such as NFS or AFS), your file i
s
< often not completely flushed to the remote filesystem until you close it. 
< Therefore, if you are (for example) close to your quota, and you do close(),
< it is quite possible that the close() will put you over your quota and
< therefore fail.

This sounds like very bad file system design.  If you are over some quota,
the write() that caused you to go over the quota should return an error.
The local system should determine your quota and remaining space and
check this on each write.

Furthermore, when the close() fails, you now have a program that knows
that some amount of previously written data is not valid.  How can
it determine how much?  Furthermore, can the program recover the data
from the system?  Or does this mean that a program should keep a copy
in memory of all data that is hard to reproduce until it closes the file?

In summary, this behaviour of a file system is not acceptable.

						Tim Smith