Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!usc!samsung!uunet!pmafire!uudell!sequoia!rpp386!jfh
From: jfh@rpp386.cactus.org (John F Haugh II)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Message-ID: <18823@rpp386.cactus.org>
Date: 15 Dec 90 15:28:33 GMT
References: <1990Dec5.052124.28435@erg.sri.com> <10960:Dec507:07:4190@kramden.acf.nyu.edu> <1990Dec05.155248.8929@iecc.cambridge.ma.us> <6193:Dec618:43:4390@kramden.acf.nyu.edu> <1820@b15.INGR.COM>
Reply-To: jfh@rpp386.cactus.org (John F Haugh II)
Organization: Lone Star Cafe and BBS Service
Lines: 16
X-Clever-Slogan: Recycle or Die.

In article <1820@b15.INGR.COM> rob@b15.INGR.COM (Rob Lemley) writes:
>Examples please.  As stated before, when READING a file (ie: via open/read),
>there is NO WAY to determine if a block of zeros constituted an actual hole
>in the file or a disk block full of zeros.

The example of checksumming the results of stat() works pretty well.
A few weeks back there was some discussion about date roll back and
so on.  Keeping track of the exact contents of the entire inode and
file might be one form of copy protection or file validation.  You
could ignore the parts that change (like st_atime), but keep track
of the rest (like st_mtime, st_blocks, etc) along with file data.
-- 
John F. Haugh II                             UUCP: ...!cs.utexas.edu!rpp386!jfh
Ma Bell: (512) 832-8832                           Domain: jfh@rpp386.cactus.org
"While you are here, your wives and girlfriends are dating handsome American
 movie and TV stars. Stars like Tom Selleck, Bruce Willis, and Bart Simpson."