* shared_info::init_obcaseinsensitive implemented incorrectly [not found] <CADSoG1so=3KxR5TS6mVNRhZGkdUku42Y=S3eWV0dtDgiZE8Tww@mail.gmail.com> @ 2012-02-21 8:59 ` Nick Lowe 2012-02-21 9:11 ` Nick Lowe 2012-02-21 9:43 ` Corinna Vinschen 0 siblings, 2 replies; 9+ messages in thread From: Nick Lowe @ 2012-02-21 8:59 UTC (permalink / raw) To: cygwin Dear Cygwin Developers, shared_info::init_obcaseinsensitive in shared.cc has, in my opinion, been implemented incorrectly. The value of the obcaseinsensitive value in the registry only represents how the object manager will be on next reboot and not its present state. Cygwin uses it as if it represents the present state, however. This is likely to be true, but is not guaranteed to be. To determine the present state, first get the system root path via either: 1) Querying the %SystemRoot% environment variable via RtlExpandEnvironmentStrings_U and change it with RtlDosPathNameToNtPathName_U (alternatively RtlDosPathNameToNtPathName_U_WithStatus in Vista and later). 2) Querying the symbolic link target of \SystemRoot via NtQuerySymbolicLinkObject. (Requires administrative rights.) Then, check for existence of the uppercase form of the path with NtQueryAttributesFile ensuring, obviously, that the OBJ_CASE_INSENSITIVE flag is not set. If the the NTSTATUS value is successful, the object manager is running with case insensitivity, if not its running with case sensitivity. With regards, Nick Lowe -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 8:59 ` shared_info::init_obcaseinsensitive implemented incorrectly Nick Lowe @ 2012-02-21 9:11 ` Nick Lowe 2012-02-21 9:53 ` Nick Lowe 2012-02-21 9:43 ` Corinna Vinschen 1 sibling, 1 reply; 9+ messages in thread From: Nick Lowe @ 2012-02-21 9:11 UTC (permalink / raw) To: cygwin Grr, I hit send before finishing writing this. I meant to write: "Then, check for existence of the uppercase or lowercase form of the path (choose appropriate casing based on the existing casing) with NtQueryAttributesFile ensuring, obviously, that the OBJ_CASE_INSENSITIVE flag is not set." Cheers, Nick On Tue, Feb 21, 2012 at 8:59 AM, Nick Lowe <nick.lowe@gmail.com> wrote: > Dear Cygwin Developers, > > shared_info::init_obcaseinsensitive in shared.cc has, in my opinion, > been implemented incorrectly. > > The value of the obcaseinsensitive value in the registry only > represents how the object manager will be on next reboot and not its > present state. Cygwin uses it as if it represents the present state, > however. This is likely to be true, but is not guaranteed to be. > > To determine the present state, first get the system root path via either: > > 1) Querying the %SystemRoot% environment variable via > RtlExpandEnvironmentStrings_U and change it with > RtlDosPathNameToNtPathName_U (alternatively > RtlDosPathNameToNtPathName_U_WithStatus in Vista and later). > > 2) Querying the symbolic link target of \SystemRoot via > NtQuerySymbolicLinkObject. (Requires administrative rights.) > > Then, check for existence of the uppercase form of the path with > NtQueryAttributesFile ensuring, obviously, that the > OBJ_CASE_INSENSITIVE flag is not set. > > If the the NTSTATUS value is successful, the object manager is running > with case insensitivity, if not its running with case sensitivity. > > With regards, > > Nick Lowe -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 9:11 ` Nick Lowe @ 2012-02-21 9:53 ` Nick Lowe 2012-02-21 10:26 ` Nick Lowe 0 siblings, 1 reply; 9+ messages in thread From: Nick Lowe @ 2012-02-21 9:53 UTC (permalink / raw) To: cygwin OK, fair enough, it is an edge case... I am a stickler for correctness! :P Looking at previous threads though actually, I notice that the following is documented by Microsoft regarding the obcaseinsensitive value: "If this setting is enabled, case insensitivity is enforced for all directory objects, symbolic links, and IO objects, including file objects. Disabling this setting does not allow the Win32 subsystem to become case sensitive." You could just get away with therefore, in theory, a call to NtOpenSymbolicLinkObject for \SYSTEMROOT. If it fails because it cannot be found, you know that the system is running with case sensitivity, otherwise, it is case sensitive. Regards, Nick -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 9:53 ` Nick Lowe @ 2012-02-21 10:26 ` Nick Lowe 2012-02-21 11:04 ` Corinna Vinschen 2012-02-21 11:34 ` Nick Lowe 0 siblings, 2 replies; 9+ messages in thread From: Nick Lowe @ 2012-02-21 10:26 UTC (permalink / raw) To: cygwin I have just tested this and it works. It is faster, simpler and has less overheads than querying the registry for a potentially stale value. Just call NtOpenSymbolicLinkObject for \SYSTEMROOT with a DesiredAccess of 0 and no attributes flags in the OBJECT_ATTRIBUTES structure. This will fail with STATUS_ACCESS_DENIED if the system is running with case insensitivity and STATUS_OBJECT_NAME_NOT_FOUND if running with case sensitivity. For correctness, on the off chance that a successful NTSTATUS value is returned, the system is running with case insensitivity and the handle must be closed. Regards, Nick On Tue, Feb 21, 2012 at 9:52 AM, Nick Lowe <nick.lowe@gmail.com> wrote: > OK, fair enough, it is an edge case... I am a stickler for correctness! :P > > Looking at previous threads though actually, I notice that the > following is documented by Microsoft regarding the obcaseinsensitive > value: > > "If this setting is enabled, case insensitivity is enforced for all > directory objects, symbolic links, and IO objects, including file > objects. Disabling this setting does not allow the Win32 subsystem to > become case sensitive." > > You could just get away with therefore, in theory, a call to > NtOpenSymbolicLinkObject for \SYSTEMROOT. If it fails because it > cannot be found, you know that the system is running with case > sensitivity, otherwise, it is case sensitive. > > Regards, > > Nick -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 10:26 ` Nick Lowe @ 2012-02-21 11:04 ` Corinna Vinschen 2012-02-21 11:34 ` Nick Lowe 1 sibling, 0 replies; 9+ messages in thread From: Corinna Vinschen @ 2012-02-21 11:04 UTC (permalink / raw) To: cygwin On Feb 21 10:26, Nick Lowe wrote: > I have just tested this and it works. It is faster, simpler and has > less overheads than querying the registry for a potentially stale > value. > > Just call NtOpenSymbolicLinkObject for \SYSTEMROOT with a > DesiredAccess of 0 and no attributes flags in the OBJECT_ATTRIBUTES > structure. > > This will fail with STATUS_ACCESS_DENIED if the system is running with > case insensitivity and STATUS_OBJECT_NAME_NOT_FOUND if running with > case sensitivity. > > For correctness, on the off chance that a successful NTSTATUS value is That's not an off-chance. It works for all admin accounts. > returned, the system is running with case insensitivity and the handle > must be closed. Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than NtOpenSymbolicLinkObject. NtOpenDirectoryObject will never succeed, rather it returns STATUS_OBJECT_TYPE_MISMATCH on a case insensitive system and STATUS_OBJECT_NAME_NOT_FOUND on a case sensitive system. And then there's Windows 2000 which is always case sensitive. But I documented to require the registry key for least surprise, see http://cygwin.com/cygwin-ug-net/using-specialnames.html#pathnames-casesensitive I'm going to add this to the Cygwin DLL, but right now I have to debug another problem. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 10:26 ` Nick Lowe 2012-02-21 11:04 ` Corinna Vinschen @ 2012-02-21 11:34 ` Nick Lowe 2012-02-21 11:56 ` Corinna Vinschen 1 sibling, 1 reply; 9+ messages in thread From: Nick Lowe @ 2012-02-21 11:34 UTC (permalink / raw) To: cygwin I really should subscribe to get individual messages and not just the digest so that I can reply properly. Sorry! > Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than NtOpenSymbolicLinkObject. I would have thought that NtOpenSymbolicLinkObject would have been the more correct approach as the object expected is a symbolic link. No? >That's not an off-chance. It works for all admin accounts. Hmm, strange. Unless the query (0x1) symbolic link specific access right is specified, I always get STATUS_ACCESS_DENIED. With it specified, it succeeds as an administrator or fails otherwise. (I have only tested this under 64-bit Windows 7.) Regards, Nick On Tue, Feb 21, 2012 at 10:26 AM, Nick Lowe <nick.lowe@gmail.com> wrote: > I have just tested this and it works. It is faster, simpler and has > less overheads than querying the registry for a potentially stale > value. > > Just call NtOpenSymbolicLinkObject for \SYSTEMROOT with a > DesiredAccess of 0 and no attributes flags in the OBJECT_ATTRIBUTES > structure. > > This will fail with STATUS_ACCESS_DENIED if the system is running with > case insensitivity and STATUS_OBJECT_NAME_NOT_FOUND if running with > case sensitivity. > > For correctness, on the off chance that a successful NTSTATUS value is > returned, the system is running with case insensitivity and the handle > must be closed. > > Regards, > > Nick > > On Tue, Feb 21, 2012 at 9:52 AM, Nick Lowe <nick.lowe@gmail.com> wrote: >> OK, fair enough, it is an edge case... I am a stickler for correctness! :P >> >> Looking at previous threads though actually, I notice that the >> following is documented by Microsoft regarding the obcaseinsensitive >> value: >> >> "If this setting is enabled, case insensitivity is enforced for all >> directory objects, symbolic links, and IO objects, including file >> objects. Disabling this setting does not allow the Win32 subsystem to >> become case sensitive." >> >> You could just get away with therefore, in theory, a call to >> NtOpenSymbolicLinkObject for \SYSTEMROOT. If it fails because it >> cannot be found, you know that the system is running with case >> sensitivity, otherwise, it is case sensitive. >> >> Regards, >> >> Nick -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 11:34 ` Nick Lowe @ 2012-02-21 11:56 ` Corinna Vinschen 2012-02-21 17:12 ` Corinna Vinschen 0 siblings, 1 reply; 9+ messages in thread From: Corinna Vinschen @ 2012-02-21 11:56 UTC (permalink / raw) To: cygwin Please, don't http://cygwin.com/acronyms/#TOFU On Feb 21 11:34, Nick Lowe wrote: > I really should subscribe to get individual messages and not just the > digest so that I can reply properly. Sorry! > > > Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than NtOpenSymbolicLinkObject. > > I would have thought that NtOpenSymbolicLinkObject would have been the > more correct approach as the object expected is a symbolic link. No? Depends on what you define as correct. Since you only call the function to find out the state of case sensitivity and don't need the handle, why not use a function which you know fails in a specific way? > >That's not an off-chance. It works for all admin accounts. > > Hmm, strange. Unless the query (0x1) symbolic link specific access > right is specified, I always get STATUS_ACCESS_DENIED. With it > specified, it succeeds as an administrator or fails otherwise. I missed that. You're right, with a 0 access mask it fails with STATUS_ACCESS_DENIED. Well, it works one way or the other, right? :) Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 11:56 ` Corinna Vinschen @ 2012-02-21 17:12 ` Corinna Vinschen 0 siblings, 0 replies; 9+ messages in thread From: Corinna Vinschen @ 2012-02-21 17:12 UTC (permalink / raw) To: cygwin On Feb 21 12:55, Corinna Vinschen wrote: > > > Please, don't http://cygwin.com/acronyms/#TOFU > > > On Feb 21 11:34, Nick Lowe wrote: > > I really should subscribe to get individual messages and not just the > > digest so that I can reply properly. Sorry! > > > > > Just call NtOpenDirectoryObject on \\SYSTEMROOT, rather than NtOpenSymbolicLinkObject. > > > > I would have thought that NtOpenSymbolicLinkObject would have been the > > more correct approach as the object expected is a symbolic link. No? > > Depends on what you define as correct. Since you only call the function > to find out the state of case sensitivity and don't need the handle, > why not use a function which you know fails in a specific way? > > > >That's not an off-chance. It works for all admin accounts. > > > > Hmm, strange. Unless the query (0x1) symbolic link specific access > > right is specified, I always get STATUS_ACCESS_DENIED. With it > > specified, it succeeds as an administrator or fails otherwise. > > I missed that. You're right, with a 0 access mask it fails with > STATUS_ACCESS_DENIED. Well, it works one way or the other, right? :) I applied a matching patch: http://cygwin.com/ml/cygwin-cvs/2012-q1/msg00115.html Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
* Re: shared_info::init_obcaseinsensitive implemented incorrectly 2012-02-21 8:59 ` shared_info::init_obcaseinsensitive implemented incorrectly Nick Lowe 2012-02-21 9:11 ` Nick Lowe @ 2012-02-21 9:43 ` Corinna Vinschen 1 sibling, 0 replies; 9+ messages in thread From: Corinna Vinschen @ 2012-02-21 9:43 UTC (permalink / raw) To: cygwin On Feb 21 08:59, Nick Lowe wrote: > Dear Cygwin Developers, > > shared_info::init_obcaseinsensitive in shared.cc has, in my opinion, > been implemented incorrectly. > > The value of the obcaseinsensitive value in the registry only > represents how the object manager will be on next reboot and not its > present state. Cygwin uses it as if it represents the present state, > however. This is likely to be true, but is not guaranteed to be. > > To determine the present state, first get the system root path via either: > > 1) Querying the %SystemRoot% environment variable via > RtlExpandEnvironmentStrings_U and change it with > RtlDosPathNameToNtPathName_U (alternatively > RtlDosPathNameToNtPathName_U_WithStatus in Vista and later). > > 2) Querying the symbolic link target of \SystemRoot via > NtQuerySymbolicLinkObject. (Requires administrative rights.) > > Then, check for existence of the uppercase form of the path with > NtQueryAttributesFile ensuring, obviously, that the > OBJ_CASE_INSENSITIVE flag is not set. > > If the the NTSTATUS value is successful, the object manager is running > with case insensitivity, if not its running with case sensitivity. Sorry, but that's much too complicated. This code is supposed to be fast. And the obcaseinsensitive setting in the registry is not something which is going to be changed a lot. And those who change it know that it only has an effect after reboot, so they will reboot soon. I'm perfectly fine with the fact that Cygwin will not be quite right until the next reboot in this case. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Project Co-Leader cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2012-02-21 17:12 UTC | newest] Thread overview: 9+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <CADSoG1so=3KxR5TS6mVNRhZGkdUku42Y=S3eWV0dtDgiZE8Tww@mail.gmail.com> 2012-02-21 8:59 ` shared_info::init_obcaseinsensitive implemented incorrectly Nick Lowe 2012-02-21 9:11 ` Nick Lowe 2012-02-21 9:53 ` Nick Lowe 2012-02-21 10:26 ` Nick Lowe 2012-02-21 11:04 ` Corinna Vinschen 2012-02-21 11:34 ` Nick Lowe 2012-02-21 11:56 ` Corinna Vinschen 2012-02-21 17:12 ` Corinna Vinschen 2012-02-21 9:43 ` Corinna Vinschen
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).