Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!usc!apple!oliveb!amiga!cbmvax!jesup From: jesup@cbmvax.commodore.com (Randell Jesup) Newsgroups: comp.sys.amiga.tech Subject: Re: when is a block not a block? Message-ID: <13571@cbmvax.commodore.com> Date: 2 Aug 90 01:45:35 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> Reply-To: jesup@cbmvax (Randell Jesup) Organization: Commodore, West Chester, PA Lines: 39 In article ked01@JUTS.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. ... >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. Second, since filesystems are separate from Dos as a very basic level, the only way you could ever even answer the question would be to have a packet for specifically asking the filesystem if it has enough space (at the moment). Filesystems can store the data any way they want. Hell, they could lempel-ziv encode them into data blocks, or allocate storage on the byte level between files, etc, etc. 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. -- 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!"