Path: utzoo!utgpu!news-server.csri.toronto.edu!rutgers!cs.utexas.edu!uunet!world!bzs From: bzs@world.std.com (Barry Shein) Newsgroups: comp.unix.internals Subject: Re: holes in files Message-ID: Date: 15 Dec 90 23:20:20 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> <18823@rpp386.cactus.org> Sender: bzs@world.std.com (Barry Shein) Organization: The World Lines: 20 In-Reply-To: jfh@rpp386.cactus.org's message of 15 Dec 90 15:28:33 GMT Although this doesn't work in practice it seems that getrusage()'s ru_inblocks ought to tell you the actual number of blocks read, in which case that number wouldn't increment when you read a hole. So you could watch your rusage structure to detect holes. Right now ru_inblocks doesn't increment when the block was in the cache, which I suppose is honest in some sense, but I don't think it would be too odd if the only case it didn't increment on were when a hole was read. Perhaps that would take another structure element (one to indicate blocks read by the process and another to indicate how many blocks actually had to be retrieved from a device or were already in the cache, either way.) -- -Barry Shein Software Tool & Die | {xylogics,uunet}!world!bzs | bzs@world.std.com Purveyors to the Trade | Voice: 617-739-0202 | Login: 617-739-WRLD