🚀 go-pugleaf

In article <d4eQ02U2010201@JUTS.ccc.amdahl.com> ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) writes:
>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.

	We'll report the amount of space left, but neither we nor Unix (nor
I suspect VMS) guarantee a specific number of blocks used to store a file.
Unix is slightly less variable, due to preallocation of inodes, but even it
varies (bsd storing of small files in partial blocks, etc).

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

	The caller should be aware that since it doesn't know exactly the
algorithms used by the filesystem to store the data, there's no way to be 
certain of your interpretation of whether the file will fit (even if nothing
else is happening).

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

	It's fairly simple to write a file of null/garbage data of the given
length, and see whether it succeeds (or under 2.0 use SetFileSize to get the
filesystem to do it for you - even faster).

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

	Get the Atlanta Devcon notes from CATS.

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

	That doesn't work if the allocation sizes are variable (there are
other gotcha's as well).  I think my previous statement stands: the size
reported is a reasonable approximation, but there can be no guarantee of
correlation with other values/objects.

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