Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!julius.cs.uiuc.edu!wuarchive!sdd.hp.com!uakari.primate.wisc.edu!uflorida!haven!adm!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: Trojan Horses
Message-ID: <19547:Oct1818:25:2690@kramden.acf.nyu.edu>
Date: 18 Oct 90 18:25:26 GMT
References: <BZS.90Oct6191703@world.std.com> <BZS.90Oct17215707@world.std.com> <1990Oct18.121818.9956@athena.mit.edu>
Organization: IR
Lines: 20

In article <1990Oct18.121818.9956@athena.mit.edu> jik@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