On 5/23/20 3:49 PM, Erich E. Hoover wrote:
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.
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
Best, Erch