🚀 go-pugleaf

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