[PATCH 3/3] wbemprox: Get the disk drive serial number from mountmgr.

[Zebediah Figura]

On 5/23/20 3:49 PM, Erich E. Hoover wrote:
> On Sat, May 23, 2020 at 1:01 PM Zebediah Figura <z.figura12 at gmail.com> wrote:
>> On 5/23/20 1:49 PM, Erich E. Hoover wrote:
>>> ...
>>> Unfortunately for me, the thing I'm trying to do _is_ work with the
>>> volume information - which looks like it involves figuring out how to
>>> implement IRP_MJ_QUERY_VOLUME_INFORMATION.
>>
>> Does this have to do with the problem mentioned in [1]?
> 
> Yes, I'd like to fix some rebase issues with my junction point patches
> and that now involves GetVolumeInformation getting pushed down
> further.  The right way to do this looks like implementing
> GetVolumeInformation on top of GetVolumeInformationByHandle.  To not
> break \??\Volume{...}\ this looks like it means that
> NtQueryVolumeInformationFile needs to be able to issue
> IRP_MJ_QUERY_VOLUME_INFORMATION to the mountmgr.

Yep. Broadly, this should look like other IRPs. We already have a fd op 
for it, so it'd just need to get wired up through device_file_ops and 
ntoskrnl.

> 
>> Wiring up IRP_MJ_QUERY_VOLUME_INFORMATION in mountmgr is one possible
>> approach, and maybe even the best one. I'm not really sure, though. (Of
>> course, I'm also not Alexandre.)
> 
> Another possibility could be to have the mountmgr create a special set
> of symlinks for NT devices that can be easily figured out (like we do
> for DOS devices).  I'm not sure how AJ would feel about that, but my
> gut feeling is that having the volume information in one place (like
> you mention below) would override the simplicity of creating an
> "ntdevices" concept similar to dosdevices.

Maybe. The benefit of doing this becomes less, though, if all file 
resolution goes through the server, which I am inclined to think is what 
we want.

> 
>> It'd kind of be nice for volume information to be implemented in one
>> place and not two, but this requires a lot of work (probably fully
>> implementing opening files by device path) which isn't really justified
>> by anything other than one failing test. Nevertheless, I have some ideas
>> I've described in [2].
> 
> Are we terribly concerned about performance here?  It doesn't seem
> like apps "should" be querying volume information in a
> performance-sensitive way, but "should" and "do" are often different.

Not performance of NtQueryVolumeInformationFile(), no, but if there's an 
attempt to make all files openable through device paths, that can't all 
go through mountmgr.

> 
>> [1] https://www.winehq.org/pipermail/wine-devel/2020-April/164070.html
>>
>> [2] https://bugs.winehq.org/show_bug.cgi?id=39569#c3
>> ...
> 
> Best,
> Erch
>