In my minifilter I need sector / alloc unit size on volumes my filter attaches to. For that I use FltQueryVolumeInformation / FileFsFullSizeInformation at some point after I attached to the volume (btw: is it safe to call this API in volume instance setup callback?). It works fine on disk-based volumes, however it fails on MUP (expectedly, of course). The question is what would be the best strategy to cache these properties on MUP-located files? I mean it would be wasteful to call FltQueryVolumeInformationFile on every file opened on MUP volume, so are there any tricks that helps caching these sizes for MUP-located files?
In the instance setup callback one of the parameters is VolumeDeviceType. If
it is FILE_DEVICE_NETWORK_FILE_SYSTEM then I guess it doesn’t have an
allocation size and you could probably remember that in a volume context ?
I think you should be ok calling FltQueryVolumeInformationFile from
InstanceSetup though I’m not sure what FILE_OBJECT you would be calling it
on (unless you open your own file ?). There was a mountmgr deadlock in XP I
think (described http://www.osronline.com/showThread.cfm?link=90003) but I
don’t think it should matter in your case.
Thanks,
Alex.
Thanks, Alex. My concern is that although MUP has no sector / cluster concept, redirectors maintained by MUP may have them. So, if I call FltQueryVolumeInformationFile on an actual file opened on MRxSMB (for instance), I will get sector / cluster size for the server-side FS volume. And since on Vista+ MUP “volume” is the only “volume” my minifilter is going to see for all redirectors, I’m kind of left with necessity to call FltQueryVolumeInformationFile for every single file opened on MUP “volume”. I thought that maybe there is a better way to do that.
Strictly speaking, I don’t need to call FltQueryVolumeInformationFile to obtain sector size. I can use FltQueryVolumeInformation (without the “File” suffix) that doesn’t require FILE_OBJECT. I guess, FltMgr will just open volume’s DEVICE_OBJECT, and issue appropriate CTL to it. Which may (or may not) deadlock during the mount.
Unfortunately there isn’t any other level of granularity for contexts in
this case. I think you could try something like getting the file name and
try to build a sort of context based on the server name, but what if files
on the same server are stored on volumes with different allocation sizes ?
What you need is a context associated with a volume on the remote side and I
can’t imagine how you’d do that short of adding a minifilter on the server
(the server minifilter would know which file maps to which volume on the
server) and communicating between the server and the client minifilters…
Is the allocation size even relevant in this context ? I mean, your IO to
MUP shouldn’t have any alignment requirements and then even if you actually
do perform IO at the allocation size on the server, I don’t think there are
guarantees that the IOs won’t be split to some other size as it travels over
the wire and is written to the server volume…
I don’t think you will be affected by the mountmgr deadlock anyway for this
call because FltQueryVolumeInformation doesn’t return the volume name but
rather device names, which it should be able to figure out without asking
the MountMgr.
Thanks,
Alex.
I need sector / cluster size on the filtering volume in order to properly calculate allocation size for my encrypted files (I have an encryption filter that doesn’t preserve file sizes). Maybe it’s not a big deal, but I want IFSTEST to be happy 
So, I need to track APIs that set / return file sizes (Query/SetInfo, DirControl, etc.) and do the math, which requires knowing the allocation size on filtering volume.
I think, I can live with having to call FltQueryVolumeInformationFile for every file (once for every FCB) on redirector, but it was worth trying to see if there are other options
Thanks again!
I think it is impossible to know the sector and cluster size for SMB/CIFS.
–
Maxim S. Shatskih
Windows DDK MVP
xxxxx@storagecraft.com
http://www.storagecraft.com
wrote in message news:xxxxx@ntfsd…
> In my minifilter I need sector / alloc unit size on volumes my filter attaches to. For that I use FltQueryVolumeInformation / FileFsFullSizeInformation at some point after I attached to the volume (btw: is it safe to call this API in volume instance setup callback?). It works fine on disk-based volumes, however it fails on MUP (expectedly, of course). The question is what would be the best strategy to cache these properties on MUP-located files? I mean it would be wasteful to call FltQueryVolumeInformationFile on every file opened on MUP volume, so are there any tricks that helps caching these sizes for MUP-located files?
>