I would recommend you call this in your callback for IRP_MJ_CREATE operations for calls on a newly mounted volume, and then store it for later recall. What I did was add a new UNICODE_STRING in my DEVICE_EXTENSION struct called DriveLetter to store this for later use.
Then simply call this in the function that handles the creates:
NTSTATUS MapDeviceVolumeToDosName(
IN PDEVICE_OBJECT DeviceObject,
IN PCARINA_DEVICE_EXTENSION devExt,
IN PIRP Irp
)
{
NTSTATUS status = STATUS_SUCCESS;
if( Irp->RequestorMode == UserMode &&
devExt->DriveLetter.Length < 1 &&
IS_VALID_MOUNT_TO_MAP(DeviceObject->DeviceType) )
{
#if WINVER >= 0x0501
status = IoVolumeDeviceToDosName(
devExt->StorageStackDeviceObject,
&devExt->DriveLetter );
#else
status = RtlVolumeDeviceToDosName(
devExt->StorageStackDeviceObject,
&devExt->DriveLetter );
#endif
}
return status;
}
A few things to note include the fact you have to pass the device object from storage stack and not one created by the filter, and that the IS_VALID_MOUNT_TO_MAP is similar to the IS_DESIRED_DEVICE_TYPE macro used in the samples in the IFS kit, modified to my liking. Other than that… you should be good to go.
Of course, if you move to the new minifilter architecture, you will find that name resolution is MUCH cleaner and easier to use.
Good luck.
xxxxx@lenovo.com wrote:
Tony,thank you to reply for my question quickly.
Do you know the RtlVolumeDeviceToDosName routine how to translate
DeviceName to DosName?I use this routine get DosName(e.g C:),it work usually well but once in
while BugCheck.Best Regards
Ken Wang
“Tony Mason”
ÊÕ¼þÈË£º “Windows File Systems Devs Interest List”
> ·¢¼þÈË£º
> xxxxx@lis ³ËÍ£º
> ts.osr.com Ö÷Ì⣺ RE: [ntfsd] How can i get a full pathname in IRP_MJ_CREATE
> dispath routine?
>
> 2005-02-26 21:56
> Çë´ð¸´ ¸ø “Windows File
> Systems Devs Interest
> List”
>
>
>
>
>
> The question itself presumes that there is a full pathname to retrieve,
> which isn’t necessarily the case.
>
> If we ignore those cases where a path name is not available, you obtain
> it (in dispatch as you specified) by taking the name in the file
> object and combining it with the name you previously stored (usually in
> a table) for the RelatedFileObject field (not often used). The name of
> the current file object is in the FileName field. If there is no
> RelatedFileObject, that is the entire name of the file - including path
> - that will be given to the file system, relative to the root of the
> volume.
>
> You cannot safely use the RelatedFileObject->FileName; while it might
> appear to work properly for you to use that information, there is no
> guarantee that this is true.
>
> The cases in which you cannot obtain a full path name in IRP_MJ_CREATE
> would include the open by file ID and open by object ID cases (where a
> 64 bit or 128 bit number are used to identify the file). In such a
> case, you can obtain a path by opening the file and querying the file
> system for the name. I do want to emphasize that you will only receive A
> path to the file. If the file has multiple paths to it (e.g., hard
> links) then what you get back is “arbitrary” (and determined by the
> specific underlying file system). If the context in which you are
> operating does not have SeChangeNotify privilege (rare, but it can
> happen) you cannot query the path (you will get back
> STATUS_ACCESS_DENIED or STATUS_PRIVILEGE_NOT_HELD as I recall). Perhaps
> you do not care about these cases, but they do exist.
>
> One other thing to keep in mind here: the “root of the volume” may not
> mean beginning at the drive letter. If someone uses a volume mount
> point, then the “root of the volume” will be relative to that volume
> mount point - not relative to the drive letter. For example, I
> routinely use this on my development system, so even though I have 10
> disks attached to the system, it appears as if there is only a single
> drive letter - C: with specific volumes “mounted” within subdirectories.
>
> Unfortunately, what many people believe is simple (obtaining the “name”
> of a file) is actually one of the more complicated aspects of Windows
> file systems. The rich naming environment supported by the OS
> translates into a correspondingly complex implementation model for a
> file system filter that wishes to determine the name.
>
> Regards,
>
> Tony
>
> Tony Mason
> Consulting Partner
> OSR Open Systems Resources, Inc.
> http://www.osr.com
>
>
> -----Original Message-----
> From: xxxxx@lists.osr.com
> [mailto:xxxxx@lists.osr.com] On Behalf Of xxxxx@lenovo.com
> Sent: Saturday, February 26, 2005 1:31 AM
> To: ntfsd redirect
> Subject: [ntfsd] How can i get a full pathname in IRP_MJ_CREATE dispath
> routine?
>
> How can i get a full pathname in IRP_MJ_CREATE dispath routine?
>
> Best Regards
>
> Ken Wang
>
>
>
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: xxxxx@osr.com
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
> —
> Questions? First check the IFS FAQ at
> https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to ntfsd as: unknown lmsubst tag argument: ‘’
> To unsubscribe send a blank email to xxxxx@lists.osr.com
>
>
>
> —
> Questions? First check the IFS FAQ at https://www.osronline.com/article.cfm?id=17
>
> You are currently subscribed to $subst(‘List.Name’) as: $subst(‘Recip.EmailAddr’)
> To unsubscribe send a blank email to $subst(‘Email.UnSub’)
–
Regards,
Dana Epp
[Blog: http://silverstr.ufies.org/blog/]