🚀 go-pugleaf

In article <3fco02lsb9LE01@amdahl.uts.amdahl.com> ked01@juts.ccc.amdahl.com (Kim DeVaughn) writes:
>> 	Actually, it looks to be counting extension blocks as well as data
>> blocks, but not header blocks (since you can have them while having no
>> data at all).  One could argue this is more accurate, since those extension
>> blocks are used in storing the data, though they don't contain data
>> themselves.
>
>Yeah ... that is what it looks to be ... but I've been burned by a "pretty
>face" before, too :-)
>
>Are you saying this is now the documented behavior for the fib_NumBlocks
>entry (for the FFS), or is it still better to compute them yourself from
>fib_Size, so as not to break in future releases?

	Computing it yourself is never really safe.  It depends on how the
FS works internally.  Take what it gives you, with the understanding that
this really is only an internal measure of storage to the filesystem.  On some
filesystems I can imagine (easily), the number of blocks a file takes may
depend on fragmentation.  Certainly the number of blocks can and will
vary from filesystem to filesystem for a given file.

	I advise against writing code that uses blocks for anything more than
user informational display or hints.

>OK, I won't (yet, anyway :-) ) ... but can you say if the hash-table size
>is still fixed at "72", and if it isn't fixed, how one finds out that
>info (the field in the root block struct ?)

	I don't know, that's Steve's baby.  The various blocks have always
been defined as <size - X> for things towards the end, with the table in
the middle.

-- 
Randell Jesup, Keeper of AmigaDos, Commodore Engineering.
{uunet|rutgers}!cbmvax!jesup, jesup@cbmvax.cbm.commodore.com  BIX: rjesup  
Common phrase heard at Amiga Devcon '89: "It's in there!"