Path: utzoo!utgpu!news-server.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!zaphod.mps.ohio-state.edu!sdd.hp.com!decwrl!apple!sun-barr!newstop!sun!amdahl!JUTS!ked01 From: ked01@ccc.amdahl.com (Kim DeVaughn) Newsgroups: comp.sys.amiga.tech Subject: Re: when is a block not a block? Summary: when it's a block on a multitasking OS ...? Message-ID: Date: 3 Aug 90 09:32:15 GMT References: <6498.269a4527@vax1.tcd.ie> <648H02l0b8KM01@amdahl.uts.amdahl.com> <13237@cbmvax.commodore.com> <3fco02lsb9LE01@amdahl.uts.amdahl.com> <13342@cbmvax.commodore.com> <13571@cbmvax.commodore.com> Reply-To: ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 75 In article <13571@cbmvax.commodore.com> jesup@cbmvax (Randell Jesup) writes: > > In article 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