Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!wuarchive!mit-eddie!mit-amt!snorkelwacker!spdcc!ima!esegue!johnl
From: johnl@esegue.segue.boston.ma.us (John R. Levine)
Newsgroups: comp.unix.questions
Subject: Re: sparse files
Message-ID: <1989Dec14.155833.1246@esegue.segue.boston.ma.us>
Date: 14 Dec 89 15:58:33 GMT
References: <21581@adm.BRL.MIL> <235@dg.dg.com> <2700@auspex.auspex.com> <1989Dec13.172444.27531@esegue.segue.boston.ma.us> <11813@smoke.BRL.MIL>
Reply-To: johnl@esegue.segue.boston.ma.us (John R. Levine)
Organization: Segue Software, Cambridge MA
Lines: 19

In article <11813@smoke.BRL.MIL> gwyn@brl.arpa (Doug Gwyn) writes:
>One problem with sparse files is that simply updating can result in an I/O
>failure if the original record overlapped a hole and the file system doesn't
>have any more free data blocks.
>
>I don't offer a solution for this, just a warning that even I/O operations
>that "can't" fail might, so applications should always check and be prepared
>to recover.

Given the traditional tendency for disks to fail at the least convenient
time in the least convenient way, one should be prepared for any write to
fail as a disk block that used to be good becomes bad.  Doug's point is well
taken, though, since your error routine might be prepared for a write error
which makes a write() return -1, but not an out of space error which tends
to return a positive number less than the amount you wanted to write.
-- 
John R. Levine, Segue Software, POB 349, Cambridge MA 02238, +1 617 864 9650
johnl@esegue.segue.boston.ma.us, {ima|lotus|spdcc}!esegue!johnl
"Now, we are all jelly doughnuts."