Trojan Horses

Dan Bernstein brnstnd at kramden.acf.nyu.edu
Fri Oct 19 04:25:26 AEST 1990


In article <1990Oct18.121818.9956 at athena.mit.edu> jik at athena.mit.edu (Jonathan I. Kamens) writes:
>   If you are working on a remote filesystem (such as NFS or AFS), your file is
> 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 is a failure of NFS, not a reason to check close(). (Well, close()
should be restarted on EINTR, but that's a side issue.) It's not right
to give the programmer the burden of working around NFS's bugs. Same for
AFS.

You allude to a real problem, though: an application may have to deal
with disk-full errors on any write(). An fwaste(fd,n) syscall, to
allocate n bytes for a file, would solve this. (Note that this is
different from the proposed fextend(fd,n), which changes the length of
the file but zero-fills rather than allocate space on disk.
ftruncate(fd,n) is the opposite of each.)

---Dan



More information about the Comp.unix.internals mailing list