On Wed Jul 3 21:48:26 2024 +0000, Elizabeth Figura wrote:
Oh yeah, right. And the major difference between first NtOpenFile
attempt and the second are different file names ("\??\D:" on first attempt vs "\??\D:\" on second attempt) which you mentioned. Sorry I got tripped by that access flag difference which is probably essentially irrelevant. Oops, you're right. I actually did *not* notice that and completely forgot it worked that way.
But still, the is a fallback path in
NtQueryVolumeInformationFile(FileFsAttributeInformation) which tries to read from block device directly. If there is a certainty that everything should go through dbus now (including all the archs), then probably that path should be removed? I don't know the answer to whether we want to depend on mountmgr being able to enumerate all devices. It'd certainly be nice if we can. Either way, though, the message "unable to read serial and label" is inaccurate, since we *do* require mountmgr for that one, and mountmgr requires having an actual volume enumerated (it doesn't try to read from the block device like the old code did). There's a fallback for drive type, but none for label and serial. So we should probably just remove it.
Delete that message, sure, can do
(sorry for lateness, waited until this convo finished then forgot it)