Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!att!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!think.com!barmar
From: barmar@think.com (Barry Margolin)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Message-ID: <1990Dec26.190535.25820@Think.COM>
Date: 26 Dec 90 19:05:35 GMT
References: <1820@b15.INGR.COM> <2809@cirrusl.UUCP> <11749@alice.att.com>
Sender: news@Think.COM
Organization: Thinking Machines Corporation, Cambridge MA, USA
Lines: 32

In article <11749@alice.att.com> andrew@alice.att.com (Andrew Hume) writes:
>	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. 

Sounds like a pretty unrobust protocol.  A simple protocol can't be
expected to deal with complicated situations.

>	   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.

A more immediate fear should be WORM read-write file systems.  I don't know
about the current generation of WORM FS standards, but a proposal I saw
several years ago at MIT specified that any time a block is modified such
that a 1 bit is replaced with a 0 bit a new block is allocated for the new
contents of the block, the old block is marked obsolete, and the inode is
changed to point to the new block (WORM media is like paper tape and
punched cards -- you can add 1 bits, but you can't take any way).  Thus,
overwriting a non-zero block could result in a file system full error!
--
Barry Margolin, Thinking Machines Corp.

barmar@think.com
{uunet,harvard}!think!barmar