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

[Erich E. Hoover]

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.

> 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.

> 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.

> [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