Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!uunet!lll-winken!sun-barr!newstop!sun!amdahl!JUTS!ked01 From: ked01@ccc.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech Subject: Re: when is a block not a block? Message-ID: Date: 5 Aug 90 02:18:08 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> <10797@wehi.dn.mu.oz> Reply-To: ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 65 In article <10797@wehi.dn.mu.oz> BAXTER_A@wehi.dn.mu.oz writes: > > You know how big the space is, yes? So you want to know how big the file is. > Copy it to Nil:/Null: and cout the bytes on the way. It will be quick enough > to not make much difference (Unless the file is enormous, in which case, you > will have some idea of if it will fit :-) The "size" of a file is a bit trickier than just knowing the number of bytes it's length is (which BTW, can be found directly by looking at fib_Size ... at least I *think* that it documented to be accurate ... Randell ?) What matters when (say) copying a file, is the number of allocatable entities it will occupy (i.e., blocks), some of which do not contain any of the file's data, per se (header and extension blocks, for example). As Randell has pointed out, this number can be variable, even for a given file on some (as yet hypothetical) file system. And that the value of fib_NumBlocks can only be considered to be a rough indicator of a file's actual allocation (for which there is NO supported way of determining). At present (1.3 OFS and FFS), the true block allocation of a file can be found with a simple computation, as "ls" v4.0k does. Whether or not that can be done in the future is not known, nor is there any requirement on future filesystems to provide such information as would make that possible. I wish it were otherwise, and that one could count on fib_NumBlocks to return the true allocation of a file (or some varient thereof as the OFS is documented to do, and that it "seems" the FFS does), but that is NOT a requirement, based on what has been said here. Seemingly, the only real "requirement" on a filesystem is that it must be self- consistent, and only its device drivers need have knowledge of things like the blocking/allocation methods used. The rest of the "system", such as utilities, must simply take what they can get WRT information about files, and must be "aware" that any such information may not be accurate. Thus, they should do nothing of a critical nature with anything based on this info, and should use it for "informational purposes" only. Actually, I ran into a good example of this kind of thing when working on "ls". The "pathass" utility allows you make "assignments" which can span different real devices. So you can "assign" (say) foo: to df0:c and dh2:c together, and then refer to file "bar" as foo:bar, where "bar" may be in either real dir. Obviously, such a "device" has no id_BytesPerBlock, since part of the "device" is on an OFS, and part on an FFS. Calling Info() on such a puppy, correctly returns an error, so I was able to pump out a warning msg, to the effect that the block counts may be inaccurate, and then just use the value found in the fib_NumBlocks entry for each file, bypassing the "actual number of blocks" calculation. No huhu. While I understand that other such "oddities" may well arise in the future, what bothers me is not being able to ask the filesystem for the *true* info in a supported way. /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