[Bug 39569] Multiple applications using ntdll.NtQueryObject 'ObjectNameInformation' info class get incorrect names for file objects

[WineHQ Bugzilla]

https://bugs.winehq.org/show_bug.cgi?id=39569

Zebediah Figura <z.figura12 at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |z.figura12 at gmail.com

--- Comment #3 from Zebediah Figura <z.figura12 at gmail.com> ---
There are a number of difficulties I see in solving this:

(1) We currently rely on mountmgr to create devices, including determining the
device type. But we run into a bootstrapping problem, because various
components (including wineboot) need to access the C: and Z: drives before
mountmgr is even started.

One way to solve this is to retain the current symlinks and drive resolution
logic from ntdll, and fall back to it if creating a device on the server side
fails.

Another way to solve this is to create at least the C and Z volumes from the
server side. Probably in that case we'd want the server to have a server-side
"volume" device object, that mountmgr creates? Or maybe mountmgr should somehow
replace the drives or the symlinks once it's started?

(2) Generally, retaining current performance. While feeding file operations
directly through to mountmgr as if it were any other NT kernel driver would
work fine, the overhead is pretty significant (RPC to the server for each file
operation, and another essentially two RPCs from mountmgr to the server.) This
can be improved dramatically by keeping unix fds cached the same way we do now
(I guess we'd want a way for mountmgr to tell the server to associate a given
unix fd with its device file?) but that doesn't help create or close requests
(which require a server call anyway, but at least it was just one server call).

The most obvious way to solve this is, as was partially proposed to fix problem
(1), to have the server keep track of volumes specially. In that case I'm not
even sure mountmgr would create volume devices directly, but rather it would
probably go through some "create_volume" server request, passing through the
mount point.

-- 
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.