What is the relationship between EOF, FileSize in FCB and FileSize in SharedCacheMap

NTFSD
1

During my development of a filter, I found that when I moved EOF the filesize in FCB will change synchronously; when I chang the filesize in FCB the EOF was also moved. Beside, the filesize in SharedCacheMap seems useless and less participation, what is the relationship between these three variables?
Any help will be appreciated!!!

2

The EOF in the common header belongs to the file system (or your filter if you are doing an isolation filter and this is your file object rather than the shadow file object). Nobody else should be looking at or modifying this value.

The purpose of CcSetFileSizes is to tell Cc what the current file sizes are. AllocationSize is most important to Mm (since it indicates the size of the section) with ValidDataLength and EOF being most important to Cc (they dictate the handling of CcCopyRead calls, for example). Cc doesn’t know how big a file is (EOF) unless you tell it.

A read between VDL and EOF will be zero filled. A read below VDL will be satisfied by copying it from the mapped view of the section into the given buffer.

Cc manages its views in units of 256KB.

Applications get their sense of file size from either IRP_MJ_QUERY_INFORMATION (standard information or network open information) or via the fast I/O call (one for each - with query network open being the special fast I/O call that takes an IRP) or the directory entry information (which includes sizes). You can watch a trace of an application to figure out which one it is using.

Tony
OSR

3

Thank you, Tony.
What you said about “Application get their sense of file size” is correct in most situations(such as notepad.exe and some other programs), but it seems strange when I test for wordpad.exe, wordpad.exe seems neither send an IRP_MJ_QUERY_INFORMATION nor fast I/O call, of course the directory entry information isn’t its way, how does it get the file size?
I use FileSpy to track the requests about wordpad.exe, but get nothing usefule :frowning:
(My test environment is Windows XP SP Professional 2)

4

There’s no magic here, so there is a call that provides this information, you just aren’t getting it.

You don’t see an IRP_MJ_DIRECTORY_CONTROL?

Tony
OSR

5

Yes, I saw an IRP_MJ_DIRECTORY_CONTROL request and I handled this request with the following codes:
pFileBothDirInfo = iopb->Parameters.DirectoryControl.QueryDirectory.DirectoryBuffer;
while(1){
if (pFileBothDirInfo->CreationTime.QuadPart < KS_YEARS_LIMIT)
{
pFileBothDirInfo->EndOfFile.QuadPart -= FS_HEADER_SIZE + FS_FILE_KEY_SIZE;
pFileBothDirInfo->CreationTime.QuadPart += KS_YEARS;
}

if (pFileBothDirInfo->NextEntryOffset == 0)
{
break;
} else {
pFileBothDirInfo = (unsigned char*)pFileBothDirInfo + pFileBothDirInfo->NextEntryOffset;
}
}
The size of the file seems really changed by checking the attribute of the file, but if opened by wordpad.exe, the length of the file is still the bigger one(not changed and different from the attribute value)

6

Getting a file size is not a must to load a document.

Probably wordpad just reads the stream till EOF.

–
Maxim S. Shatskih
Microsoft MVP on File System And Storage
xxxxx@storagecraft.com
http://www.storagecraft.comd

wrote in message news:xxxxx@ntfsd…
> Thank you, Tony.
> What you said about “Application get their sense of file size” is correct in most situations(such as notepad.exe and some other programs), but it seems strange when I test for wordpad.exe, wordpad.exe seems neither send an IRP_MJ_QUERY_INFORMATION nor fast I/O call, of course the directory entry information isn’t its way, how does it get the file size?
> I use FileSpy to track the requests about wordpad.exe, but get nothing usefule :frowning:
> (My test environment is Windows XP SP Professional 2)
>