Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!hsdndev!cmcl2!kramden.acf.nyu.edu!brnstnd
From: brnstnd@kramden.acf.nyu.edu (Dan Bernstein)
Newsgroups: comp.unix.internals
Subject: Re: holes in files
Message-ID: <8266:Dec1622:32:0990@kramden.acf.nyu.edu>
Date: 16 Dec 90 22:32:09 GMT
References: <6193:Dec618:43:4390@kramden.acf.nyu.edu> <1820@b15.INGR.COM> <18823@rpp386.cactus.org>
Organization: IR
Lines: 16

In article <18823@rpp386.cactus.org> jfh@rpp386.cactus.org (John F Haugh II) writes:
> 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.

Right. Another realistic example is that many sites run a program to
search for all files of a particular type---setuid, for instance. Some
such programs work by generating an ls-type output, then ``diff''ing
the list from the previous list and sending a message to the admin about
any changes. If the block size changes sporadically, the admin will get
false alarms.

---Dan