OS4 equivalent for fib_NumBlocks

This forum is for general developer support questions.
Post Reply
JosDuchIt
Posts: 291
Joined: Sun Jun 26, 2011 5:47 pm
Contact:

OS4 equivalent for fib_NumBlocks

Post by JosDuchIt »

In struct FileInfoBlock fib_NumBlocks gives us the number of blocks for a file. This structure is obsolete under OS4
In struct ExamineData, to be used instead of it, there is however no equivalent for fib_NumBlocks

How can one have this info under OS4 ?
User avatar
nbache
Beta Tester
Beta Tester
Posts: 1714
Joined: Mon Dec 20, 2010 7:25 pm
Location: Copenhagen, Denmark
Contact:

Re: OS4 equivalent for fib_NumBlocks

Post by nbache »

JosDuchIt wrote:In struct FileInfoBlock fib_NumBlocks gives us the number of blocks for a file. This structure is obsolete under OS4
In struct ExamineData, to be used instead of it, there is however no equivalent for fib_NumBlocks

How can one have this info under OS4 ?
I guess you could do an Info(), read the id_BytesPerBlock, divide the filesize by that, and round up the number to the next integer?

BTW, just curious: Why would you want to know the number of blocks a file takes up anyway?

Best regards,

Niels
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1479
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: OS4 equivalent for fib_NumBlocks

Post by tonyw »

The concept of "blocks" depends on the device and the filesystem. It is a legacy from the days of floppy disks when all sectors were 256 or 512 bytes long. These days a "block" is an internal thing that the filesystem defines and uses for its own purposes. What the filesystem calls "a block" may vary with the context - it may be part of a sector, exactly one sector, or many disk sectors. The "number of bytes per block" that is specified in Media Toolbox may bear no resemblance to any hardware structure.

As Niels said, why would you want to know? It's probably not a good idea to tell the user how many "blocks" a file occupies, because you only have the file size that the filesystem told you, and that may not be the whole truth, anyway. For instance, if the disk has 512-byte sectors or blocks, a 2000-byte file (that is still open for write) might take up 4x512-byte blocks. But if the filesystem has allocated 64 kB for the file (assuming it will be extended further before it is closed), the answer might be 128 blocks right now, and 4 blocks after the file is closed. Only the file size (2000 bytes) is really significant.
cheers
tony
User avatar
abalaban
Beta Tester
Beta Tester
Posts: 456
Joined: Mon Dec 20, 2010 2:09 pm
Location: France
Contact:

Re: OS4 equivalent for fib_NumBlocks

Post by abalaban »

What would be interesting fro the user is to do what Windows does (Yes I really said that ;-) by telling both the file size *and* the size the file actually occupies on the disk. This helps users understand why he's missing some space on his disk.
AmigaOne X1000 running AOS 4 beta
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
JosDuchIt
Posts: 291
Joined: Sun Jun 26, 2011 5:47 pm
Contact:

Re: OS4 equivalent for fib_NumBlocks

Post by JosDuchIt »

@nbache

BTW, just curious: Why would you want to know the number of blocks a file takes up anyway?
It's because the 68k version of Gui4Cli can give this info to the programmer. I don't see what harm it can do in his hands
I can think at least of one reason maybe why this could be interesting to the user
Many small files that don't use the blocks completely make for slow (backup) communications. Right? Wrong?
To do some automatic or manual optimalization you need the length of each file the nr of blocks and the size of the blocks.
NumBlocks is stil used for function giving info on volumes, so why not for files?
To know the real size taken up by a drawer, wouldn't it be more correct to express it in NumBlocks x BlockSize ?
@tonyw
But if the filesystem has allocated 64 kB for the file (assuming it will be extended further before it is closed), the answer might be 128 blocks right now, and 4 blocks after the file is closed. Only the file size (2000 bytes) is really significant.
In the light of the example of knowing the real size taken up by a drawer, say in a directory manager, one can expect that hardly one file will stll be open.
User avatar
tonyw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 1479
Joined: Wed Mar 09, 2011 1:36 pm
Location: Sydney, Australia

Re: OS4 equivalent for fib_NumBlocks

Post by tonyw »

Many small files that don't use the blocks completely make for slow (backup) communications. Right? Wrong?
Not quite right. Any program reading any file won't read past the end-of-file mark, so it doesn't matter how much unused space there is at the end of a file, it won't be copied or backed up.
cheers
tony
User avatar
colinw
AmigaOS Core Developer
AmigaOS Core Developer
Posts: 207
Joined: Mon Aug 15, 2011 9:20 am
Location: Brisbane, QLD. Australia.

Re: OS4 equivalent for fib_NumBlocks

Post by colinw »

I don't know why you would still want to display this obsolete and pointless info, but that's your business.

The Examine() / ExNext() emulator in the V53 dos.library uses the following code to cook up a value
for this old field, just for compatibility purposes....
You'll need to do a GetDiskInfo() first, have the examinedata for the object.


uint32 numblocks32 = 0;

if( EXD_IS_FILE(examinedata) )
{
if( infodata->id_BytesPerBlock )
{
numblocks32 = filesize32 / infodata->id_BytesPerBlock;

if(( filesize32 % infodata->id_BytesPerBlock) != 0 )
{
numblocks32 ++; /* one more block for partial fit */
}
}
}
if( ! numblocks32 ) /* if a dir or 0 - software can't handle 0 */
{
numblocks32 ++;
}
JosDuchIt
Posts: 291
Joined: Sun Jun 26, 2011 5:47 pm
Contact:

Re: OS4 equivalent for fib_NumBlocks

Post by JosDuchIt »

@ColinW
Thanks
Post Reply