Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.19
Hi Corinna, I notice you are still reading in obcaseinsensitive in cygcheck.cc but this value is no longer used in Cygwin as you have dropped Windows 2000 support. Would it make sense to change the code there to show the actual state of case sensitivity? Kind 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
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.19
I do not think I explained myself properly, sorry: Cygwin would previously read the obcaseinsensitve value under Windows 2000 to emulate the case insensitive behaviour of Windows XP and newer where obcaseinsensitive was present in the registry. The registry key does not represent the active state of case sensitivity, so it is surely the wrong thing to query and show in cygcheck as it only shows what the state is pending a reboot. Surely it would be better now to query how the case sensitivity actually is here and show that, and get rid of all references to obcaseinsensitive, which is a configuration parameter and private implementation detail of kernel? 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
Re: [ANNOUNCEMENT] Updated: Cygwin 1.7.19
Nick, was it you, who wrote this article? http://www.nicklowe.org/2012/02/understanding-case-sensitivity-in-windows-obcaseinsensitive-file_case_sensitive_search/ Thanks for it, if so. But the more frustrating it makes your post, as article clearly states, that I did, yes. I was trying to get my head around it and the design a year or so ago and decided to document it as I could find nothing substantive available on the Web. At the time, I noticed that Corinna special cased Windows 2000 to keep reading obcaseinsensitive in the patch that was otherwise committed to test for the actual state of case sensitivity instead: http://cygwin.com/ml/cygwin-cvs/2012-q1/msg00115.html It is a mess and pretty frustrating! You have to be very careful about the assumptions that you make in your code. 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
Re: Intermittent failures retrieving process exit codes
Briefly casting my eye at the test case, as a general point, remember that these termination APIs all complete asynchronously and I do not believe it has ever been safe or correct to call another while one is still pending - you are in undefined, edge case behaviour territory here. Win32's TerminateThread/ExitThread, that in turn calls the native NtTerminateThread, only requests cancellation of a thread and returns immediately. One has to wait on a handle to the thread know that termination has completed, for which the synchronise standard access right is required. The same is true of Win32's TerminateProcess/ExitProcess, in turn NtTerminateProcess, where one waits instead on a handle to the process. 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
Re: Intermittent failures retrieving process exit codes
The documentation in MSDN is incorrect/incomplete with regards to TerminateThread/TerminateProcess, both are definitely asynchronous. I am not clear/confident on the behaviour of ExitProcess and ExitThread, but will investigate with IDA and a test case later. I suspect any locking/serialisation will pertain to these functions only. On Fri, Dec 21, 2012 at 7:44 PM, Tom Honermann thonerm...@coverity.com wrote: On 12/21/2012 07:15 AM, Nick Lowe wrote: Briefly casting my eye at the test case, as a general point, remember that these termination APIs all complete asynchronously and I do not believe it has ever been safe or correct to call another while one is still pending - you are in undefined, edge case behaviour territory here. These comments do not match my understanding of these APIs. MSDN documentation contradicts some of this as well. Win32's TerminateThread/ExitThread, that in turn calls the native NtTerminateThread, only requests cancellation of a thread and returns immediately. One has to wait on a handle to the thread know that termination has completed, for which the synchronise standard access right is required. The same is true of Win32's TerminateProcess/ExitProcess, in turn NtTerminateProcess, where one waits instead on a handle to the process. TerminateProcess() is documented to perform error checking and then to schedule asynchronous termination of the specified process. I would not be surprised if the asynchronous termination applies even when GetCurrentProcess() is used to specify the process to terminate, but I would likewise not be surprised if TerminateProcess() has special handling for this. I agree that calls to TerminateProcess() might return before the calling thread/process is terminated. I have not tried to verify this behavior though. http://msdn.microsoft.com/en-us/library/windows/desktop/ms686714%28v=vs.85%29.aspx The MSDN documentation for TerminateThread() does not state that the termination is carried out asynchronously, but I would not be surprised if that is the case. http://msdn.microsoft.com/en-us/library/windows/desktop/ms686717%28v=vs.85%29.aspx I would be *very* surprised if it is possible for ExitProcess() and ExitThread() to return (unless the thread is being suspended and its context manipulated by another process/thread). The MSDN docs for these do not mention any possibility of return. In addition, the ExitThread() documentation explicitly states that Windows manages serialization of calls to ExitProcess() and ExitThread(). quote The ExitProcess, ExitThread, CreateThread, CreateRemoteThread functions, and a process that is starting (as the result of a CreateProcess call) are serialized between each other within a process. Only one of these events can happen in an address space at a time. /quote http://msdn.microsoft.com/en-us/library/windows/desktop/ms682659%28v=vs.85%29.aspx http://msdn.microsoft.com/en-us/library/windows/desktop/ms682658%28v=vs.85%29.aspx I read that quote as supporting my assertion that the observed behavior is a defect in Windows. It appears Windows is failing to serialize the calls appropriately. Tom. -- 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 -- 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
Re: Trusted Software Vendor
To me, the key question is: Would Red Hat have an objection in principle to signing Cygwin and its packages given the history and ties. -- 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
Re: Trusted Software Vendor
http://cygwin.com/ The Cygwin DLL and utilities are Copyright © 2000, 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012 Red Hat, Inc Wikipedia isn't the keeper of the information relevant to Cygwin. You can only find the truth at cygwin.com. Besides, companies do support open source projects by providing man hours to it. It doesn't mean that the company providing those hours has any other right to it than you or I do. Cygwin is a separate entity from 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
Re: Windows 8 Release Preview. fork problems with rsync
Urgh! Hmm.. Do you see the same effect when running the process in
question under the Windows 8 operating system context?
If you manifest and include:
compatibility xmlns=urn:schemas-microsoft-com:compatibility.v1
application
!--The ID below indicates application support for Windows Vista --
supportedOS Id={e2011457-1546-43c5-a5fe-008deee3d3f0}/
!--The ID below indicates application support for Windows 7 --
supportedOS Id={35138b9a-5d96-4fbd-8e2d-a2440225f93a}/
!--The ID below indicates application support for Windows 8 --
supportedOS Id={4a2f28e3-53b9-4441-ba9c-d69d4a4a6e38}/
/application
/compatibility
http://msdn.microsoft.com/en-us/library/windows/desktop/hh848036(v=vs.85).aspx
Does the odd behaviour still persist?
Could it be possibly be something to do with the fault tolerant heap
(FTH) and changes they've made to it? I would try ensuring that is
switched off too...
(Process Hacker will show the context of a running process.)
Nick
Thanks. I can confirm the effect. For no apparent reason, the OS
reserves a 1 Megs shared memory region, top-down allocated, of which it
uses about 20K. It's not the PEB or one of the TEBs, though. Nor is
it a thread stack. I checked, and it turns out that it's allocated
in every process, on 32 and 64 bit systems. That's kind of worrying
since that's bound to collide with mmaped regions and pthread stacks a
lot. I don't know what to do at this point.
--
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
Re: Can't access 'some' SMB network drives from ssh or cron
Have you taken a Wireshark capture in both scenarios and looked for differences? 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
Re: Can't access 'some' SMB network drives from ssh or cron
Have you taken a Wireshark capture in both scenarios and looked for differences? Wireshark capture of an encrypted stream is next to useless... Is SMB encrypted in this case? -- 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
Re: [OT] renaming file immediately after close fails problem
Are you waiting for the file handle to become signalled before attempting a rename? Nick On Wed, May 16, 2012 at 11:46 AM, Václav Zeman vhais...@gmail.com wrote: Hi. This is unrelated to Cygwin directly. I am having problems in my library that renaming files sometimes fails right after the file is closed. I vaguely remember seeing same or similar problems being discussed in this mailing list but I cannot find the emails. Could any of you remember discussions about this problem and its conclusions? -- VZ -- 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 -- 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
Re: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
Yeah - Sorry all for any misunderstanding on my part. I seem to remember I was in a caustic mood at the time anyway over something very unrelated! Will take care to not derail threads in the future. 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
Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?
Is there a reason why the Cygwin executables, and certainly the installer, are not digitally signed by Redhat? Also, with reference to: http://blogs.msdn.com/b/cjacks/archive/2009/03/27/manifesting-for-compatibility-on-windows-7.aspx http://msdn.microsoft.com/en-us/library/dd371711%28v=vs.85%29.aspx Should the Cygwin executables should be manifested so that they cannot run under any PCA compatibility shim and get the Windows 7 'behaviour'? -- 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
Re: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
It's bad etiquette to derail an email thread with unrelated questions. I certainly didn't mean to derail it, the other points were ancillary to the implicit point that I intended to make which is that if the executable was digitally signed, any potential corruption would immediately be flagged by the operating system. -- 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
Re: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
I installed 2.772 on my systems as soon as it was available and I don't see any such issue using my local mirror. Did you try another mirror? Quite, but the idea of corruption was implicit in that question. A digital signature would rule that out. It was only a suggestion to ensure that that would never be a possibility. What's with the hostility? It's really bad etiquette... ;) 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
Re: Using Red Hat digital signing on setup.exe (was Re: Cygwin 1.7.14-2 setup.exe v2.772 broken?)
I forgot to add, it also needs to be signed by a trusted root for it to be useful to most people. On Sun, Apr 29, 2012 at 1:51 AM, Nick Lowe nick.l...@gmail.com wrote: I installed 2.772 on my systems as soon as it was available and I don't see any such issue using my local mirror. Did you try another mirror? Quite, but the idea of corruption was implicit in that question. A digital signature would rule that out. It was only a suggestion to ensure that that would never be a possibility. What's with the hostility? It's really bad etiquette... ;) 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
Re: Cygwin | Cygwin Compatibility Issue report ID 386608.
Dear Microsoft, Which version did you test? See the following thread: http://cygwin.com/ml/cygwin-developers/2011-10/threads.html#5 Re: Add support for Windows 8, first step Regards, Nick On Fri, Apr 27, 2012 at 1:05 AM, Anuja Singh (MP Tech Consulting LLC) v-anu...@microsoft.com wrote: find_fast_cwd -- 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
Re: OpenSSL 1.0.1-1 does not seem to support engine aesni
In 1.0.1: http://www.openssl.org/news/changelog.html Add RC4-MD5 and AESNI-SHA1 stitched implementations. This work was sponsored by Intel. [Andy Polyakov] -- 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
Re: OpenSSL 1.0.1-1 does not seem to support engine aesni
Oh, sorry, yes. I suspect that the AES-NI instructions are used 'silently' where supported by the processor. -- 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
shared_info::init_obcaseinsensitive implemented incorrectly
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
Re: shared_info::init_obcaseinsensitive implemented incorrectly
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.l...@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
Re: shared_info::init_obcaseinsensitive implemented incorrectly
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
Re: shared_info::init_obcaseinsensitive implemented incorrectly
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.l...@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
Re: shared_info::init_obcaseinsensitive implemented incorrectly
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.l...@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.l...@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
