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