EldoS | Feel safer!

Software components for data protection, secure storage and transfer

NtcreateFile with allocation size not working

Also by EldoS: CallbackDisk
Create virtual disks backed by memory or custom location, expose disk images as disks and more.
#12013
Posted: 12/30/2009 08:35:14
by Mezeo Support (Basic support level)
Joined: 12/29/2009
Posts: 40

I tried creating a file on a file system (developed using Eldos) using NtcreateFile which allow us to specify allocation size and later queried FileStandardInfo for that file. I observed allocation size to be 0 and not the one I specified in NtCreateFile call.

OnSetAllocationSize and OnSetEndOfFile callbacks didnt get called. Allocation size at file creation time is supported or not ?
#12044
Posted: 01/05/2010 06:07:12
by Mezeo Support (Basic support level)
Joined: 12/29/2009
Posts: 40

Allocation size at file creation time is supported or not in last release ?
#12046
Posted: 01/05/2010 06:27:55
by Volodymyr Zinin (EldoS Corp.)

It should be supported. If you call NtCreateFile with the allocation size specified then right after the OnCreateFile callback the OnSetAllocationSize callback should be called. If it isn't then please tell me and specify the action you are performing (so I will be able to reproduce it).
Of course after the file has been closed and reopened again it's allocation size can be reported to be equal to the "end of file" size.
#12049
Posted: 01/05/2010 08:58:53
by Mezeo Support (Basic support level)
Joined: 12/29/2009
Posts: 40

OnSetAllocationSize callback not getting called. Test utility performs below steps


HMODULE hModule = LoadLibrary(_T("C:\\Windows\\System32\\ntdll.dll"));

if(NULL == hModule){
printf("LoadLibrary failed with %d\n",GetLastError());
return 0;
}


pCreatf = (Creatf) GetProcAddress( hModule, "NtCreateFile");
if(NULL == pCreatf){
printf("GetProcAddress failed with %d\n",GetLastError());
return 0;
}


TCHAR *fName = _T("\\DosDevices\\M:\\my files\\test.dat");
int len = _tcslen(fName);
ObjectName.Length = len * sizeof(TCHAR);
ObjectName.MaximumLength = ObjectName.Length + sizeof(TCHAR);
ObjectName.Buffer = fName;

InitializeObjectAttributes(
&ObjectAttributes,
&ObjectName,
0x00000080L ,
NULL,
NULL
);

AllocationSize.LowPart = 10000;
AllocationSize.HighPart = 0;

status = pCreatf(&FileHandle, GENERIC_READ | GENERIC_WRITE | FILE_READ_DATA | FILE_WRITE_DATA | SYNCHRONIZE,
&ObjectAttributes,
&IoStatusBlock,
&AllocationSize,
FILE_ATTRIBUTE_NORMAL,
0,
0x00000005, //FILE_OVERWRITE_IF,
0, //FILE_NON_DIRECTORY_FILE,
NULL,
0
);

FILE_STANDARD_INFO fileinfo;
if(!GetFileInformationByHandleEx(
FileHandle,
FileStandardInfo ,
&fileinfo,
sizeof(FILE_STANDARD_INFO)
))
{
printf("%d \n", GetLastError());
}
#12061
Posted: 01/06/2010 04:37:12
by Volodymyr Zinin (EldoS Corp.)

I have checked it with the C++ Mounter sample and it works (the OnSetAllocationSize callback is called after OnCreate).
Check your CallbackFS implementation. Perhaps there is an error there.

BTW: Instead of the code specified above I used the FileTest utility taken from http://www.zezula.net. It's convenient to use it for FS testing.
#12064
Posted: 01/06/2010 06:28:16
by Mezeo Support (Basic support level)
Joined: 12/29/2009
Posts: 40

You are right. I tried using Filetest.

When I specify \??\M:\My Files\Mayur as relative path, test as file name, allocation size to be 1010, disposition FILE_OVERWRITE_IF
I get create callback followed by set allocation with 4112.

When I close the file I get set allocation callback with size 0 and then close callback.I have not understood why should second set allocation callback with size 0 be called ?

But If I don't specify relative path but absolute path I am not getting any set allocation size callback which seems to be strange to me.
#12065
Posted: 01/06/2010 14:43:37
by Volodymyr Zinin (EldoS Corp.)

I've tried both cases with and without the "relative path" field and the behavior is the same. Perhaps either you miss to set the allocation size in the second call or the file is still opened and its allocation size is equal or greater to the one which is set. Please check it.

Quote
Mayur Thigale wrote:
I have not understood why should second set allocation callback with size 0 be called ?

Because when a file is closed it isn't necessary for it to have any extra space. So CallbackFS calls the SetAllocationSize callback with the size equal to the "end of file" size (i.e. the file real data size). But it's up to your FS implementation to leave any allocation space (for example to round the allocation size on a cluster border).
#12066
Posted: 01/07/2010 00:41:16
by Mezeo Support (Basic support level)
Joined: 12/29/2009
Posts: 40

Quote
I've tried both cases with and without the "relative path" field and the behavior is the same. Perhaps either you miss to set the allocation size in the second call or the file is still opened and its allocation size is equal or greater to the one which is set. Please check it.


I tried it again but set the allocation size callback didn't get called.

Quote
Because when a file is closed it isn't necessary for it to have any extra space. So CallbackFS calls the SetAllocationSize callback with the size equal to the "end of file" size (i.e. the file real data size). But it's up to your FS implementation to leave any allocation space (for example to round the allocation size on a cluster border).


It is not possible to identify SetAllocationSize callback getting called from user mode explicit request or from your driver in above case. It seems windows file systems ntfs/fat doesn't behave this way.
#12067
Posted: 01/07/2010 02:45:51
by Volodymyr Zinin (EldoS Corp.)

Quote
Mayur Thigale wrote:
I tried it again but set the allocation size callback didn't get called.

Are you using your own CallbackFS implementation or one of CallbackFS samples? In the former case please try on a sample (I checked it on the C++ Mounter sample).

Quote
Mayur Thigale wrote:
It is not possible to identify SetAllocationSize callback getting called from user mode explicit request or from your driver in above case. It seems windows file systems ntfs/fat doesn't behave this way.

Yes, it isn't possible. But why is it necessary for you? Allocation size is necessary only if someone (the system or a user that performs file I/O) wants to reserve space on a disk for file's data that will be written later (in order the write data operation performed later not to be finished with the "out of space" error). When a file is closed then any extra space (more then the file real data size, i.e. EOF) isn't necessary. FATFS and NTFS work in the same way. Of course FATFS always rounds the allocation size to be equal to the cluster size but NTFS in case of placing small files into MFT records rounds their allocation size to 8 bytes (or some similar size).
Also by EldoS: Rethync
The cross-platform framework that simplifies synchronizing data between mobile and desktop applications and servers and cloud storages

Reply

Statistics

Topic viewed 4070 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!