Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!att!dptg!ulysses!andante!alice!andrew
From: andrew@alice.att.com (Andrew Hume)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Summary: que?
Message-ID: <11749@alice.att.com>
Date: 26 Dec 90 06:33:23 GMT
References: <6193:Dec618:43:4390@kramden.acf.nyu.edu> <1820@b15.INGR.COM> <2809@cirrusl.UUCP>
Organization: AT&T Bell Laboratories, Murray Hill NJ
Lines: 27

In article <2809@cirrusl.UUCP>, dhesi%cirrusl@oliveb.ATC.olivetti.com (Rahul Dhesi) writes:
~ In <8432:Dec1622:40:0790@kramden.acf.nyu.edu>
~ brnstnd@kramden.acf.nyu.edu (Dan Bernstein) writes:
~ 
~    I want to make sure that blocks 17 through 22 (expressed in byte
~    sizes) will be guaranteed not to run out of space when I write to
~    them. You're saying that I should have no way to make this
~    guarantee.
~ 
~ Well, "df" works nicely.


	I rate this as a completely fatuous answer, devoid of
use and common sense. i had a similar problem. a network server
gets a request from a client to store a file of given length.
it is not permissible to say yes and then say no halfway through
the file. i do it by writing zeros to the given length first
and then saying yes/no and then read/write the actual data.
when do i do the df, exactly? actually, from what this thread has
uncovered, it might be safer to write non-zero data to avoid
smart filesystems. what scares me more are hyperintelligent
disk drives that have built in data compression and might be able
to take 20 blocks of some values but not be able to overwrite them
because of different compression rates.

	andrew hume
	andrew@research.att.com