Path: utzoo!attcan!uunet!decwrl!apple!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: answer: when it's a block Message-ID: Date: 30 Jul 90 07:46:16 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: ked01@JUTS.ccc.amdahl.com (Kim DeVaughn) Organization: Amdahl Corporation, Sunnyvale, CA 94086 Lines: 33 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 -- 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