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 ?
OS4 equivalent for fib_NumBlocks
- nbache
- Beta Tester
- Posts: 1714
- Joined: Mon Dec 20, 2010 7:25 pm
- Location: Copenhagen, Denmark
- Contact:
Re: OS4 equivalent for fib_NumBlocks
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?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 ?
BTW, just curious: Why would you want to know the number of blocks a file takes up anyway?
Best regards,
Niels
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: OS4 equivalent for fib_NumBlocks
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.
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
tony
Re: OS4 equivalent for fib_NumBlocks
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
AmigaOne XE/G4
Amiga 1200/PPC 603e + BVision PPC
Re: OS4 equivalent for fib_NumBlocks
@nbache
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
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 handsBTW, just curious: Why would you want to know the number of blocks a file takes up anyway?
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
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.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.
- tonyw
- AmigaOS Core Developer
- Posts: 1479
- Joined: Wed Mar 09, 2011 1:36 pm
- Location: Sydney, Australia
Re: OS4 equivalent for fib_NumBlocks
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.Many small files that don't use the blocks completely make for slow (backup) communications. Right? Wrong?
cheers
tony
tony
- colinw
- AmigaOS Core Developer
- Posts: 207
- Joined: Mon Aug 15, 2011 9:20 am
- Location: Brisbane, QLD. Australia.
Re: OS4 equivalent for fib_NumBlocks
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 ++;
}
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 ++;
}
Re: OS4 equivalent for fib_NumBlocks
@ColinW
Thanks
Thanks