Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!ucsd!pacbell.com!pacbell!amdahl!JUTS!ked01 From: ked01@ccc.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech Subject: Re: when is a block not a block? Summary: whenever ... Message-ID: Date: 5 Aug 90 02:44:31 GMT References: <6498.269a4527@vax1.tcd.ie> <648H02l0b8KM01@amdahl.uts.amdahl.com> <13237@cbmvax.commodore.com> <3fco02lsb9LE01@amdahl.uts.amdahl.com> <13342@cbmvax.commodore.com> <13571@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > > We'll report the amount of space left, but neither we nor Unix (nor > I suspect VMS) guarantee a specific number of blocks used to store a file. > Unix is slightly less variable, due to preallocation of inodes, but even it > varies (bsd storing of small files in partial blocks, etc). That's fine. I wasn't looking for any "guarantees". Is it possible that you can do the same for the actual number of blocks (or some variant thereof) used by a file via fib_NumBlocks or a similar mechanism? > The caller should be aware that since it doesn't know exactly the > algorithms used by the filesystem to store the data, there's no way to be > certain of your interpretation of whether the file will fit (even if nothing > else is happening). True, but it can be a real good "sanity check" at times. No guarantees tho. > It's fairly simple to write a file of null/garbage data of the given > length, and see whether it succeeds (or under 2.0 use SetFileSize to get the > filesystem to do it for you - even faster). 2.0 sounds better and better all the time! Thanks for all the "goodies"! > >When and where will > >all this "good stuff in 2.0" be documented (for the masses)? > > Get the Atlanta Devcon notes from CATS. I wasn't aware that they were available yet? What's the cost ... my check is all made out except for that item ... :-) > That doesn't work if the allocation sizes are variable (there are > other gotcha's as well). I think my previous statement stands: the size > reported is a reasonable approximation, but there can be no guarantee of > correlation with other values/objects. I've run into one (pathass), as I mentioned in a previous posting, but that was won a "logical" psuedo-device. What real devices vary their allocations in the way you're suggesting? Thanks for all the info on this stuff Randell ... it is appreciated, and may keep a few of us from falling in a deep, dark hole in the future! /kim -- UUCP: kim@uts.amdahl.com -OR- ked01@juts.ccc.amdahl.com or: {sun,decwrl,hplabs,pyramid,uunet,oliveb,ames}!amdahl!kim DDD: 408-746-8462 USPS: Amdahl Corp. M/S 249, 1250 E. Arques Av, Sunnyvale, CA 94086 BIX: kdevaughn GEnie: K.DEVAUGHN CIS: 76535,25