Path: utzoo!attcan!uunet!cs.utexas.edu!yale!cmcl2!kramden.acf.nyu.edu!brnstnd From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein) Newsgroups: comp.unix.internals Subject: Re: On the silliness of close() giving EDQUOT Message-ID: <9681:Oct2004:06:3090@kramden.acf.nyu.edu> Date: 20 Oct 90 04:06:30 GMT References: <1990Oct18.200939.17427@athena.mit.edu> <24048:Oct1822:23:2090@kramden.acf.nyu.edu> Organization: IR Lines: 30 In article thurlow@convex.com (Robert Thurlow) writes: > In <24048:Oct1822:23:2090@kramden.acf.nyu.edu> brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes: > >["I don't mind close returning -1/EINTR and -1/EBADF."] > >No other close() errors make sense. > So how do you pick up errors on asynchronous writes? That is an excellent question. I suspect that if UNIX had truly asynchronous I/O, my objections would disappear, as the whole system would work much more cleanly. Somehow I'm not sure the latest mound of P1003.4 is the right way to approach asynchronous I/O, but anyway... ``What asynchronous writes?'' [ I object that programs can't afford to keep data around in case of ] [ possible problems; errors must be returned in a timely fashion ] > This is ridiculous. If a program wants to _know_ the data is secured, > it can call fsync before it frees the buffers or overwrites the data. I sympathize with what you're trying to say, but have you noticed that fsync() isn't required to flush data over NFS, any more than write() is required to return EDQUOT correctly? If write()'s errors aren't accurate, I don't know how you expect fsync() to work. > "Allocations"? I won't lightly put *any* state into my NFS server, never > mind state to take care of frivolities like close returning EDQUOT. No good remote file system is stateless. I think every complaint I've heard about NFS is caused by the ``purity'' of its stateless implementation. ---Dan