Is it possible to get the “kind” of volume a network drive letter represents?
For example if E: is mapped to \server\share then if I query E: this should tell me if this drive letter was removable or fixed drive (on the other side)?
For non-network, ZwQueryVolumeInformationFile and FILE_FS_DEVICE_INFORMATION returns this information. But for network, this call always returns the same information for any drive letter representing a network share (FILE_REMOTE_DEVICE)
Looking at smbmrx, looks like FileFsDeviceInformation is completed on the server but the rest are sent to the client and completed there. However only FileFsDeviceInformation has this useful information for me where as the other, which do get completed on the client, don’t have info regarding fixed/removable.
How can someone find-out if a network drive letter represents a fixed or removable volume?
Or how can you send (directly or indirectly) IRP_MJ_QUERY_VOLUME_INFORMATION with FileFsDeviceInformation to the other side?
Thanks
There is WNet API phich is provided by mpr.dll (e.g. WNetGetConnection, WNetOpenEnum). It is available in the user mode only.
Bronislav Gabrhelik
xxxxx@xythos.com wrote:
There is WNet API phich is provided by mpr.dll (e.g. WNetGetConnection, WNetOpenEnum). It is available in the user mode only.
No, this API is not directly accessible from kernel mode. If you need
this specific functionality then implement a user mode service to call
it on your behalf.
Pete
Bronislav Gabrhelik
NTFSD is sponsored by OSR
For our schedule of debugging and file system seminars
(including our new fs mini-filter seminar) visit:
http://www.osr.com/seminars
To unsubscribe, visit the List Server section of OSR Online at http://www.osronline.com/page.cfm?name=ListServer
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Can you explain? NETRESOUCE or the rest of the wnet api does not provide that information.
xxxxx@hotmail.com wrote:
Can you explain? NETRESOUCE or the rest of the wnet api does not provide that information.
Explain why the WNet API is not supported in kernel mode? Or explain
what I mean by sending it to a user mode service to call the API?
What information are you referring to here?
Remember that much of the WNet API is implemented through a network
provider dll which is custom to the specific redirector is is partnered.
The dll implements the calls which are the underpinnings of the API but
gathers the information for the requested information by calling into
its redirector via a custom IOCtl interface, in most cases.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
Pete please don’t derail the conversations. If you have something of value to add then do so. Read my original post, if I have questions to some of the replays I can ask them. Have some common sense man.
Bronislav claimed that this can be done using WNet. If that is possible I would like to know but I don’t think that is the case.
xxxxx@hotmail.com wrote:
Pete please don’t derail the conversations. If you have something of value to add then do so. Read my original post, if I have questions to some of the replays I can ask them. Have some common sense man.
Bronislav claimed that this can be done using WNet. If that is possible I would like to know but I don’t think that is the case.
Hey, good luck … didn’t mean to derail the topic … I’ve only been
doing this for 15 years but who am I to say.
Pete
–
Kernel Drivers
Windows File System and Device Driver Consulting
www.KernelDrivers.com
866.263.9295
It seems that Pete didn’t noticed my note that it is a USER MODE API.
Can you explain? NETRESOUCE or the rest of the wnet api does not provide that information.
You can use simply WNetGetConnection(L?x:?, uncPath, &lengthUncPath);
During enumeration the NETRESOURCE.lpLocalName contains drive letter in the form “x:” and NETRESOURCE.lpRemoteName contains UNC path to which is lpcalName mapped.
If you don’t need such detailed info there is a simple User Mode API GetDriveInfo(). Unfortunately it is not always reliable for removable media, so see MSDN KB Q244089 (http://support.microsoft.com/kb/244089/). Follow the article how to resolve corner cases.
I wonder why you need this info in kernel mode because FSDF/mini-filter doesn’t see this drive letter - it sees only local namespace on attached device. The drive “x:” is usually symbolic link in Object Manager to real device. Use WinObj to understand it. There is caveat in that mapping of remote drive is local for each logon session so you need to be impersonated before you call Object Manager API. Also logon session of Vista restricted user is different than unrestricted (administrative) user.
Note that the remote FSD doesn’t have volume device ? one criteria. I think quite reliable method to recognize if given device is remote drive is to get the lowest device on the stack IoGetDeviceAttachmentBaseRef() and evaluate DeviceType which should be FILE_DEVICE_NETWORK_FILE_SYSTEM. Maybe device characteristics might be also useful.
Regards,
Bronislav Gabrhelik
I read again your original question and I realized that I completely missed the point. It seems that your goal is to get volume info from the server side. I don’t think it is possible. What’s the point? Do you need to recognize what’s FSD behind scenes - FAT vs NTFS? In such case test some feature unsupported on FAT. eg. ACL or streams.
Bronislav Gabrhelik