Xref: utzoo comp.bugs.4bsd:1718 comp.lang.c:35768
Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!axion!uzi-9mm.fulcrum.bt.co.uk!igb
From: igb@fulcrum.bt.co.uk (Ian G Batten)
Newsgroups: comp.bugs.4bsd,comp.lang.c
Subject: Re: Complexity of reallocating storage (was users command crap)
Message-ID: <W~%&'N@uzi-9mm.fulcrum.bt.co.uk>
Date: 4 Feb 91 09:49:15 GMT
References: <5883:Feb102:05:4991@kramden.acf.nyu.edu> <1991Feb2.045119.22199@zoo.toronto.edu> <14994:Feb207:10:4791@kramden.acf.nyu.edu>
Sender: isode@fulcrum.bt.co.uk (Isode Hackers)
Organization: BT Fulcrum, Birmingham
Lines: 26

In article <14994:Feb207:10:4791@kramden.acf.nyu.edu>
brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:

> 
> >    if (chdir(newsuid) == -1)
> >     {
> >      (void) mkdir(newsuid,0700);
> 
> This cannot fail unless some renegade sysadmin changes the mode of the

Ah!  I must go out and buy the patented ``Dan Bernstein never-fill''
file system, which has infinite data space and none of those nasty
limits of the number of inodes.  You can never, ever, in user space
ensure that you have space to do IO as there will always be a timing
window between your statfs (or whatever) and the actual IO.

> >    (void) chdir("..");
> 
> This is guaranteed to work.

Really.  Tell me about it.

It was some utility --- I forget what --- screaming ``can't find ..''
which alerted me on the occasion that a renegade disk controller sprayed
a data block accross a few directories on my news machine.  Seeing that
and rapidly shutting the machine down allowed me to rescue it.