On Sat, May 23, 2020 at 1:01 PM Zebediah Figura z.figura12@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
Best, Erch