Pipe names are case sensitive.
Pipe names are currently case sensitive. This affects instmsiw.exe since the service is created as "MSIService" and connected to as "MsiService". The result is that instmsiw.exe always fails to query the service status. I have insmsiw.exe from Office 2K working (at least to get as far as installing Microsoft's version of MSI) with the patches I just sent through to wine-patches, plus the hack below (which will also fix the problem for other IPC objects). One alternative to this hack would appear to be to make sync_namespace case insensitive in wineserver, although I am not sure if that is the correct approach. It seems to me that sync_namespace must have been chosen as case sensitive for a reason, although a grep doesn't reveal anything that should obviously be case sensitive in that namespace. A third alternative would be to have find_object and create_object take a flag that forces case insensitivity even in a case sensitive namespace. Which approach is to be preferred here? Index: ntdll/path.c =================================================================== RCS file: /home/wine/wine/dlls/ntdll/path.c,v retrieving revision 1.28 diff -u -r1.28 path.c --- ntdll/path.c 13 Aug 2004 23:53:44 -0000 1.28 +++ ntdll/path.c 19 Apr 2005 05:34:20 -0000 @@ -360,6 +360,16 @@ break; } + /* This is an ugly hack that will never make it into WINE */ + if (offset == 4) + { + WCHAR *src = ptr + offset; + WCHAR *dst = ntpath->Buffer + strlenW(ntpath->Buffer); + + while (*src) + *dst++ = RtlUpcaseUnicodeChar(*src++); + *dst = 0; + } else strcatW(ntpath->Buffer, ptr + offset); ntpath->Length = strlenW(ntpath->Buffer) * sizeof(WCHAR);
On Tue, 19 Apr 2005 16:20, Troy Rollo wrote:
I have insmsiw.exe from Office 2K working (at least to get as far as installing Microsoft's version of MSI) with the patches I just sent through to wine-patches, plus the hack below (which will also fix the problem for other IPC objects).
Correction - this was the instmsiw.exe from Office XP.
Troy Rollo wrote:
Pipe names are currently case sensitive. This affects instmsiw.exe since the service is created as "MSIService" and connected to as "MsiService".
[a solution] would be to have find_object and create_object take a flag that forces case insensitivity even in a case sensitive namespace.
Yes, this is the correct approach. As you correctly noted, the namespace currently determines whether a find is case sensitive or not. There are two problems: 1. The caller of find_object currently cannot tell the function if a case insensitive search is required. 2. The namespace object should really be an NT directory object, which has no notion of case sensitivity. I plan to address (1) with a rewrite of the way the OBJECT_ATTRIBUTES structure is marshaled to the server. This will include making shared marshaling, sizing, unmarshaling and freeing routines for the structure and it contains the information about whether or not the find_object call should be case insensitive. The approach will also include marshaling of the SECURITY_DESCRIPTOR structure for the start of more NT-like access checks in the object manager. However, I have already spotted numerous places that are not correctly setting the OBJ_CASE_INSENSITIVE in the OBJECT_ATTRIBUTES structure when they should, so these will need to be fixed. Alexandre, before I start on the marshaling of the OBJECT_ATTRIBUTES structure, is this acceptable with you? Rob
Rob Shearman <rob(a)codeweavers.com> writes:
I plan to address (1) with a rewrite of the way the OBJECT_ATTRIBUTES structure is marshaled to the server. This will include making shared marshaling, sizing, unmarshaling and freeing routines for the structure and it contains the information about whether or not the find_object call should be case insensitive. The approach will also include marshaling of the SECURITY_DESCRIPTOR structure for the start of more NT-like access checks in the object manager. However, I have already spotted numerous places that are not correctly setting the OBJ_CASE_INSENSITIVE in the OBJECT_ATTRIBUTES structure when they should, so these will need to be fixed.
Alexandre, before I start on the marshaling of the OBJECT_ATTRIBUTES structure, is this acceptable with you?
It doesn't seem to me there is much to marshal in the OBJECT_ATTRIBUTES structure apart from the security descriptor, so I'm not sure what you plan to do. Also I'm not convinced at all that you can avoid making the namespace know about case sensitivity; if you allow the caller to specify it, you can create names that differ only in case which will break callers that do case insensitive lookups. -- Alexandre Julliard julliard(a)winehq.org
Alexandre Julliard wrote:
It doesn't seem to me there is much to marshal in the OBJECT_ATTRIBUTES structure apart from the security descriptor, so I'm not sure what you plan to do.
The useful fields are RootDirectory, ObjectName, Attributes (for the OBJ_INHERIT and OBJ_CASE_INSENSITIVE flags) and SecurityDescriptor. These are handled individually by server calls that use them, or not at all in some cases (for example the RootDirectory and OBJ_CASE_INSENSITIVE flag). Also, all of these should by handled by the create_object or find_object call on the server side, so it makes sense to keep them together.
Also I'm not convinced at all that you can avoid making the namespace know about case sensitivity; if you allow the caller to specify it, you can create names that differ only in case which will break callers that do case insensitive lookups.
Testing on Windows shows that case insensitive lookups use the last added object with that name. For example: Create event with name "Test" Create mutex with name "test" Open event with case insensitive name "TEst" -> fails with STATUS_OBJECT_TYPE_MISMATCH Open mutex with case insensitive name "TEst" -> succeeds Rob
participants (4)
-
Alexandre Julliard -
Rob Shearman -
Robert Shearman
-
Troy Rollo