🚀 go-pugleaf

In article <c4pK02n=01EQ01@JUTS.ccc.amdahl.com>, ked01@ccc.amdahl.com (Kim DeVaughn) writes:
> In article <13342@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes:
>>
>> In article <3fco02lsb9LE01@amdahl.uts.amdahl.com> ked01@juts.ccc.amdahl.com (Kim DeVaughn) writes:
>>
>> >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.
> 
> So the bottom line is that there is no supported* way to determine the block
> count of a file.  And hence, there is no supported method of determining if
> a file on one device will "fit" on another device without actually attempting
> the copy operation.
> 
> Unfortunate.
> 
> /kim
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 :-)

Regards Alan> 
>  -- 
> 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