🚀 go-pugleaf

In article <13571@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes:
>
> In article <c4pK02n=01EQ01@JUTS.ccc.amdahl.com> ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) writes:
>
> >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.
> 
> 	First, it's a multitasking system, and any value you determine
> (without writing the file) is no longer valid if anyone else wrote to the disk.

I know that.  I was thinking of the somewhat more common case where one wishes
to transfer files from the primary storage media (say a hard disk), to the
secondary media (such as a floppy), in a relatively controlled situation.  If
there is other activity to the target/destination device, naturally any measure
of space used/available is likely to be inaccurate.

That such is the case, does not seem to prevent other multitasking OS's (such
as UN*X, VM/CMS, MVS, etc) from reporting the available space at the time the
request is issued.  Nor does it seem to prevent AmigaDOS from doing the same
on a call to Info(), or via use of the Info command.

The use such information is put to must be left up to the calling program's
discretion, and it must be aware that in some instances, that information may
become invalid before it can be used (and take the appropriate recovery steps
in case of such an eventuality).


What I object to is this:  in the OFS, fib_NumBlocks was *documented* to be
the number of data blocks occupied by a file (at some particular moment).  In
the FFS, it was then redefined to "not be updated" (per the AmigaMail article),
which is simple not true, and indeed *appears* to be the total number of blocks
used by a file, minus one (though that is not "documented" to be so).  Then I
am told that "computing the number of blocks used" based on the filesize, and
blocking factor is not a good idea, and that any value found in fib_NumBlocks
should be considered to only be an approximation.

I think that is "unfortunate", as most frequently some simple "sanity checks"
that *could* be performed WRT file xfer'ing won't be, and will opt instead
for the brute-force "see if it fits by trying to make it fit" approach (which
is a complete waste of time, and cycles, if there is no possibility of it
being able to do so in the first place).


> 	However, there's another solution under 2.0: Open a new file, then
> do SetFileSize for the size you want.  That will make a file of the requested
> size filled with random data, or fail.  Then just write over it with your
> file.

Well that's great, and I'm glad to hear it!  That can help solve an annoying 
problem with copying files, etc (if taken advantage of).  When and where will
all this "good stuff in 2.0" be documented (for the masses)?

And nonetheless, I still want to be able to find out the number of blocks (or
whatever the smallest allocatable chunk of storage is called on a given
device) a file *really* occupies, if only for informational purposes.


/kim


P.S.  While we're talking about filesystems, etc. and 2.0 ... will 2.0 quit
      defaulting newly created files to ----rwed, and perhaps make the more
      likely assumption of ----rw-d?  And will the attribute bits be
      enforced a little bit more rigerously?

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