EldoS | Feel safer!

Software components for data protection, secure storage and transfer

CbFsGetVolumeSize Callback question

Also by EldoS: BizCrypto
Components for BizTalk® and SQL Server® Integration Services that let you securely store and transfer information in your business automation solutions.
Posted: 10/15/2009 12:18:47
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

In the GetVolumeSize callback there are four parameters that are sent back to the driver from the callback. They are;
__int64* TotalAllocationUnits,
__int64* AvailableAllocationUnits,
PDWORD SectorsPerAllocationUnit,
PDWORD BytesPerSector
Are there any limits on the size of these variables besides the natural limits imposed by the size of the variable itself?
For example, BytesPerSector is a pointer to a DWORD variable which in C++ is an unsigned 32 bit integer, so it should be able to take on values between 0 and 4294967295 (2 to the 32nd minus 1). I seem to be running into a problem when I pass back a BytesPerSector value of 1000000. Has anybody ever encountered such a problem?
Posted: 10/15/2009 12:37:08
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

I tried some different values and it seems like anything over 4096 in the BytesPerSector value causes some sort of problem. Values under 4096 seem to work. Any thoughts on this?
Posted: 10/15/2009 14:16:25
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

In my code, when the block size that my system returns to me is bigger than 4096, I adjust the values that I am returning to the driver so that the block size is 4096 and the Available Allocation Units and the Total Allocation Units are the appropriate number of 4096 byte blocks. This seems to solve all the problems I was having and seems logical to me. If any of you see some potential gotcha! that I am missing please let me know.
Posted: 10/16/2009 01:15:35
by Eugene Mayevski (EldoS Corp.)

Page size is usually a multiple of 512. 8192 bytes per sector should also work for you as this is the size used by CD ROMs.

Sincerely yours
Eugene Mayevski
Posted: 10/16/2009 01:27:33
by Volodymyr Zinin (EldoS Corp.)

Hello Sid,

The CallbackFS driver doesn't allow to return any erroneous data. In this case it finishes the "get volume size" request with error. So you need always to return a correct data from this callback in order you FS works properly.
Here the checks the driver does after the GetVolumeSize callback has been called:
if (!(SizeInfo.BytesPerSector > 0 &&
      SizeInfo.BytesPerSector % CBFS_SECTOR_ALIGNMENT == 0 &&
      SizeInfo.BytesPerSector <= CBFS_MAX_SECTOR_SIZE &&
      SizeInfo.SectorsPerAllocationUnit > 0 &&
      SizeInfo.SectorsPerAllocationUnit <= CBFS_MAX_SECTORS_PER_ALLOCATION_UNIT &&
     SizeInfo.TotalAllocationUnits.QuadPart >= SizeInfo.AvailableAllocationUnits.QuadPart &&
     CbFsMaxLarge.QuadPart / SizeInfo.SectorsPerAllocationUnit / SizeInfo.BytesPerSector >= SizeInfo.TotalAllocationUnits.QuadPart)) {

Posted: 10/16/2009 10:46:43
by Kurt Griffiths (Standard support level)
Joined: 12/08/2008
Posts: 34

Is there any benefit to using large sector and/or sectors-per-allocation-unit values? What are the recommended values?
Posted: 10/17/2009 02:54:35
by Volodymyr Zinin (EldoS Corp.)

Perhaps some programs optimize their I/O by checking storage parameters, so you can specify some truthful parameters that represent the underlying storage used from your callbacks. But because there are a lot of "real" (not virtual) storages now that don't have "obvious" storage structure (RAID, etc) maybe storage parameters are not taken into account at all.
Posted: 10/26/2009 17:31:52
by Sid Schipper (Standard support level)
Joined: 03/14/2008
Posts: 285

Sorry to take so long to get back to you.

Vladimir your comment about erroneous information doesn't really apply because the information I send back is known only to my system. These files are "virtual files" that exist in reality in my database and nowhere on any real device that Windows knows about, so CBFS or Windows cannot be doing any error checking against some entity that they know about because they don't know about my files. The only error check they could possibly be doing would be some sort of "sanity" check and that is apparently what was happening when I passed back numbers that weren't the right multiples.

Anyway, I'm satisified with the way I have things working now.
Also by EldoS: RawDisk
Access locked and protected files in Windows, read and write disks and partitions and more.



Topic viewed 2517 times

Number of guests: 1, registered members: 0, in total hidden: 0


Back to top

As of July 15, 2016 EldoS Corporation will operate as a division of /n software inc. For more information, please read the announcement.

Got it!