date:20121221

On Fri, Dec 21, 2012 at 09:49:43PM -0500, Christopher Faylor wrote:
>I actually tried Xserver before submitting my change so it certainly isn't
>a consistent problem.

Sorry, I take that back.  I tried Xserver before backing out parts of the
other change and never retried it.  Marco is right.  It's definitely broken.
I've checked in a new change and am regenerating a snapshot.

cgf

--
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

2012-12-21 Thread Nick Lowe

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  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().
>
> 
> 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.
> 
>
> 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: Intermittent failures retrieving process exit codes - snapshot test requested


On 12/21/2012 09:52 PM, Christopher Faylor wrote:

You're looking at the wrong changes.


I wasn't at the time that I wrote that :)

I noticed that you had reverted those changes.  I haven't looked at the 
new changes yet.


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

Re: Intermittent failures retrieving process exit codes - snapshot test requested

On Fri, Dec 21, 2012 at 06:08:46PM -0500, Tom Honermann wrote:
>On 12/21/2012 05:23 PM, marco atzeri wrote:
>> On 12/21/2012 8:36 PM, Christopher Faylor wrote:
>>> I tested this lightly on Windows 7 and 32-bit XP but it would be nice to
>>> hear if multi-threaded things like X work on other platforms too.
>>>
>>> If you test a snapshot, note that I'm still tracking down Ken Brown's
>>> reporte emacs regression in recent snapshots so that will still be
>>> broken.
>>>
>>> cgf
>>>
>>
>> I think the Xserver doesn't like it.
>> on 20121221 it freezes on start on W7/64
>> no issue on 20121218
>
>I was worried about this possibility after looking at the code changes. 
>  But, I haven't had to a chance to test adequately yet.  I would expect 
>indefinite blocking in dll_entry() may prevent unloading DLLs.  For 
>example, calls to dll_entry() for DLL_PROCESS_DETACH may get blocked.

You're looking at the wrong changes.

cgf

--
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 - snapshot test requested

On Fri, Dec 21, 2012 at 11:23:00PM +0100, marco atzeri wrote:
>On 12/21/2012 8:36 PM, Christopher Faylor wrote:
>> On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
>>> On Dec 21 11:10, Christopher Faylor wrote:
>>>> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
>>>>> Maybe the signal thread should really not exit by itself, but just
>>>>> wait until the TerminateThread is called.  Chris?
>>>>
>>>> If the analysis is correct, that just fixes one symptom doesn't it?
>>>> There are potentially many threads running in any Cygwin program
>>>> and it sounds like any one of them could trigger this.
>>>
>>> Right.  I guess the question is how to synchronize things so that the
>>> thread calling TerminateProcess is actually the last one, making sure
>>> its return value is used.
>>>
>>> Maybe the NtQueryInformationThread(ThreadAmILastThread) call is of some
>>> help.  Or we have to keep all thread IDs of the self-started threads
>>> available to terminate them explicitely at process exit.
>>
>> I checked in a complicated fix for this problem which only affected
>> Cygwin-created threads.  But, then, I thought about another riskier but
>> simpler fix.  That version is now in CVS and I'm generating a new
>> snapshot with it.
>>
>> I tested this lightly on Windows 7 and 32-bit XP but it would be nice to
>> hear if multi-threaded things like X work on other platforms too.
>>
>> If you test a snapshot, note that I'm still tracking down Ken Brown's
>> reporte emacs regression in recent snapshots so that will still be
>> broken.
>>
>> cgf
>>
>
>I think the Xserver doesn't like it.
>on 20121221 it freezes on start on W7/64
>no issue on 20121218

I acdtually tried Xserver before submitting my change so it certainly isn't
a consistent problem.

cgf

--
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: trouble accessing samba shares with spaces and/or parentheses

2012-12-21 Thread Andrew DeFaria


On 12/21/2012 10:51 AM, bartels wrote:

On 12/21/2012 07:30 PM, Andrew DeFaria wrote:

On 12/21/2012 10:11 AM, bartels wrote:

So where can I find strace?

Where did you look?

$ type strace
strace is /bin/strace


strace is one of my favourite toys on linux.
Somehow, I never located it on cygwin. Never just typed in the magic 
word :)
The packaging is a little different here, and the searching not so 
easy. I expected a package.
I guess my point was you coulda just typed in strace and would have been 
pleasantly surprised!
BTW: Why the insistence on mapping it to a drive letter? Everybody 
always does that and I don't understand why. Drive letters change. 
Some people hard code 'em in their scripts. This is a recipe for 
errors. Other people say sometimes that some Windows apps can't work 
with UNC paths. I don't know of any that have this problem anymore. 
Q:/ doesn't tell me where this directly is located...


No reason, really, other than the fact that Windoze forces us to 
access physical storage devices via the silly drive letters .
But if I understood you correctly this is not a physical device but 
rather a network mount.
Not using drive letters would mean I have two different presentations: 
one for local storage and one for remote storage.

So what. You have two different devices.

Yet but using drive letters means you've just made a dependency that may 
not hold true on the next system and that people sometimes hard code 
into scripts. Then you get to a machine who's owner says "Oh but I use 
my Q drive" and all your scripting is screwed. A UNC path is always 
right - drive letters sometimes cause problems.

When in Rome . . .

When in Rome I'm still and American! ;-)

Said differently, yes when I was in Rome physically myself I tried to do 
things like Romans, however if they did something I thought foolish I 
didn't continue to do it that way just because I was in Rome. YMMV.
And is there a way to mount a network share without a drive letter, 
using cygwin?
Well, as I said, you could just refer to it - no mounting required! 
(Though I believe it really does mount it in some way for the duration 
of the remote file system access...)


Or you can just do

$ # \'s doubled because bash swallows them and net use requires them.
$ net use \\share
$ net use
New connections will be remembered.

Status   Local RemoteNetwork

---
   \\\   Microsoft Windows Network
More importantly, is it possible to mount a network share, using 
cygwin, so that it becomes visible/available in explorer?
Again, no mounting is required. Open up Windows Explorer and type in the 
UNC (\\\) and there you are!


And if your question then becomes "Yeah but can applications also access 
them?" my experience has been "Well yes, of course!" (though there may 
be some Windows apps that can't I haven't hit many of them lately).
The scope of mounting seems to be limited to a process (tree). Every 
service must mount separately.

That's not been my experience.

Or have I missed something?

Might have. What have you tried?
--
Andrew DeFaria 
This space for rent


--
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 - snapshot test requested


On 12/21/2012 05:23 PM, marco atzeri wrote:

On 12/21/2012 8:36 PM, Christopher Faylor wrote:

I tested this lightly on Windows 7 and 32-bit XP but it would be nice to
hear if multi-threaded things like X work on other platforms too.

If you test a snapshot, note that I'm still tracking down Ken Brown's
reporte emacs regression in recent snapshots so that will still be
broken.

cgf



I think the Xserver doesn't like it.
on 20121221 it freezes on start on W7/64
no issue on 20121218


I was worried about this possibility after looking at the code changes. 
 But, I haven't had to a chance to test adequately yet.  I would expect 
indefinite blocking in dll_entry() may prevent unloading DLLs.  For 
example, calls to dll_entry() for DLL_PROCESS_DETACH may get blocked.


It looks to me like the changes made are insufficient to prevent the 
race.  For example, this won't address the case where an exiting thread 
releases the process lock acquired in dll_entry() before a thread 
exiting the process acquires it in pinfo::exit().  Both threads could 
still end up in an ExitThread() vs ExitProcess()/TerminateProcess() 
race.  However, this is only true for threads whose exits are not 
predicated upon an action taken by the process exiting thread after it 
has acquired the process lock in pinfo::exit().  And since the exiting 
thread must be the last thread of the process in order to hit the issue, 
this may not be a concern.


I'm not sure that a general workaround for this issue is feasible for 
all possible threads.  At least, not without hooking the Terminate* and 
Exit* Win32 APIs.  My gut tells me that a general solution requires 
waiting for thread handles to be signaled, but I haven't thought it 
completely through yet.


It looks like Chris reverted the change and checked in a new update.  I 
haven't looked at those changes yet.


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

Re: Intermittent failures retrieving process exit codes - snapshot test requested

2012-12-21 Thread marco atzeri


On 12/21/2012 8:36 PM, Christopher Faylor wrote:

On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:

On Dec 21 11:10, Christopher Faylor wrote:

On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:

Maybe the signal thread should really not exit by itself, but just
wait until the TerminateThread is called.  Chris?


If the analysis is correct, that just fixes one symptom doesn't it?
There are potentially many threads running in any Cygwin program
and it sounds like any one of them could trigger this.


Right.  I guess the question is how to synchronize things so that the
thread calling TerminateProcess is actually the last one, making sure
its return value is used.

Maybe the NtQueryInformationThread(ThreadAmILastThread) call is of some
help.  Or we have to keep all thread IDs of the self-started threads
available to terminate them explicitely at process exit.


I checked in a complicated fix for this problem which only affected
Cygwin-created threads.  But, then, I thought about another riskier but
simpler fix.  That version is now in CVS and I'm generating a new
snapshot with it.

I tested this lightly on Windows 7 and 32-bit XP but it would be nice to
hear if multi-threaded things like X work on other platforms too.

If you test a snapshot, note that I'm still tracking down Ken Brown's
reporte emacs regression in recent snapshots so that will still be
broken.

cgf



I think the Xserver doesn't like it.
on 20121221 it freezes on start on W7/64
no issue on 20121218

Regards
Marco





--
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 - snapshot test requested

2012-12-21 Thread Daniel Colascione

On 12/21/2012 11:36 AM, Christopher Faylor wrote:
> On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
>> On Dec 21 11:10, Christopher Faylor wrote:
>>> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
 Maybe the signal thread should really not exit by itself, but just
 wait until the TerminateThread is called.  Chris?
>>>
>>> If the analysis is correct, that just fixes one symptom doesn't it?
>>> There are potentially many threads running in any Cygwin program
>>> and it sounds like any one of them could trigger this.
>>
>> Right.  I guess the question is how to synchronize things so that the
>> thread calling TerminateProcess is actually the last one, making sure
>> its return value is used.
>>
>> Maybe the NtQueryInformationThread(ThreadAmILastThread) call is of some
>> help.  Or we have to keep all thread IDs of the self-started threads
>> available to terminate them explicitely at process exit.
> 
> I checked in a complicated fix for this problem which only affected
> Cygwin-created threads.  But, then, I thought about another riskier but
> simpler fix. 

Your second approach scares me. There's no global order imposed on the loader
lock and the Cygwin process lock, and Windows can take the loader lock at
virtually any time, since LoadLibrary can be used internally to implement any 
API.




signature.asc
Description: OpenPGP digital signature

Re: Intermittent failures retrieving process exit codes


On 12/21/2012 01:30 AM, Tom Honermann wrote:

I don't know which Windows releases are affected by this.  I've only
reproduced the problem (outside of Cygwin) with Wow64 processes running
on 64-bit Windows 7.  I haven't yet tried elsewhere.


I was able to reproduce the issue with a 64-bit executable compiled with 
the test case in the parent email using Microsoft's Visual Studio 2010 
x64 compiler.  This issue does not appear to be specific to support for 
running 32-bit processes on 64-bit Windows via Wow64.


I have not yet tried to reproduce this on any release of Windows other 
than 64-bit Windows 7 SP1.  I am curious about what other Windows 
releases are affected.  Please reply if you try the test case and are 
able to reproduce the problem on other Windows releases.  So far, I'm 
only aware of the issue being reproduced on multi-processor systems.  I 
suspect the problem can occur on single-processor systems as well, but 
is much less likely to.


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

Re: Intermittent failures retrieving process exit codes


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().



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.



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

Re: Intermittent failures retrieving process exit codes - snapshot test requested

On Fri, Dec 21, 2012 at 06:02:19PM +0100, Corinna Vinschen wrote:
>On Dec 21 11:10, Christopher Faylor wrote:
>> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
>> >Maybe the signal thread should really not exit by itself, but just
>> >wait until the TerminateThread is called.  Chris?
>> 
>> If the analysis is correct, that just fixes one symptom doesn't it?
>> There are potentially many threads running in any Cygwin program
>> and it sounds like any one of them could trigger this.
>
>Right.  I guess the question is how to synchronize things so that the
>thread calling TerminateProcess is actually the last one, making sure
>its return value is used.
>
>Maybe the NtQueryInformationThread(ThreadAmILastThread) call is of some
>help.  Or we have to keep all thread IDs of the self-started threads
>available to terminate them explicitely at process exit.

I checked in a complicated fix for this problem which only affected
Cygwin-created threads.  But, then, I thought about another riskier but
simpler fix.  That version is now in CVS and I'm generating a new
snapshot with it.

I tested this lightly on Windows 7 and 32-bit XP but it would be nice to
hear if multi-threaded things like X work on other platforms too.

If you test a snapshot, note that I'm still tracking down Ken Brown's
reporte emacs regression in recent snapshots so that will still be
broken.

cgf

--
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: trouble accessing samba shares with spaces and/or parentheses


On 12/21/2012 07:23 PM, Corinna Vinschen wrote:

>  So where can I find strace?

In /bin.


I don't suppose they come any easier :)

Thanks.

- bartels

--
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: trouble accessing samba shares with spaces and/or parentheses

On 12/21/2012 07:30 PM, Andrew DeFaria wrote:

On 12/21/2012 10:11 AM, bartels wrote:

So where can I find strace?

Where did you look?

$ type strace
strace is /bin/strace

strace is one of my favourite toys on linux.
Somehow, I never located it on cygwin. Never just typed in the magic word :)
The packaging is a little different here, and the searching not so easy. I
expected a package.

BTW: Why the insistence on mapping it to a drive letter? Everybody always does that and I don't understand why. Drive letters change. Some
people hard code 'em in their scripts. This is a recipe for errors. Other people say sometimes that some Windows apps can't work with UNC
paths. I don't know of any that have this problem anymore. Q:/ doesn't tell me where this directly is located...

No reason, really, other than the fact that Windoze forces us to access
physical storage devices via the silly drive letters .
Not using drive letters would mean I have two different presentations: one for
local storage and one for remote storage.
When in Rome . . .

And is there a way to mount a network share without a drive letter, using
cygwin?

More importantly, is it possible to mount a network share, using cygwin, so
that it becomes visible/available in explorer?
The scope of mounting seems to be limited to a process (tree). Every service
must mount separately.
Or have I missed something?

- bartels

--
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: trouble accessing samba shares with spaces and/or parentheses

2012-12-21 Thread Andrew DeFaria


On 12/21/2012 10:11 AM, bartels wrote:

So where can I find strace?

Where did you look?

$ type strace
strace is /bin/strace

BTW: Why the insistence on mapping it to a drive letter? Everybody 
always does that and I don't understand why. Drive letters change. Some 
people hard code 'em in their scripts. This is a recipe for errors. 
Other people say sometimes that some Windows apps can't work with UNC 
paths. I don't know of any that have this problem anymore. Q:/ doesn't 
tell me where this directly is located...

--
Andrew DeFaria 
This space for rent


--
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: trouble accessing samba shares with spaces and/or parentheses

On Dec 21 19:11, bartels wrote:
> On 12/21/2012 06:19 PM, Corinna Vinschen wrote:
> >On Dec 21 18:01, bartels wrote:
> >>On 12/21/2012 05:47 PM, Corinna Vinschen wrote:
> >>>On Dec 21 17:20, bartels wrote:
> $ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels" 
> /user:"bartels"
> The command completed successfully.
> 
> $ ls q:/
> ls: cannot access q:/: Input/output error
> >>>Please don't use DOS paths.  Use POSIX paths like /cygdrive/q instead:
> >>>http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
> >>Naturally, I tried all flavours:
> >>
> >>$ ls /cygdrive/q/
> >>ls: cannot access /cygdrive/q/: Input/output error
> >>
> >>
> >>
> >>>Works fine for me using a Linux Samba share with space in it.
> >>Okay, that leaves the parentheses as the likely troublemaker.
> >>The thing is, people bring in disks, and I have no control over their 
> >>volume / share names.
> >>
> >>Any more ideas? Where's Santa when you need him ;-)
> >"Input/output error" is just an EIO.  strace might show more useful
> >information.  EIO could be generated for a couple of reasons, for
> >instance, the WIn32 errors ERROR_DISK_CORRUPT or ERROR_OPEN_FAILED are
> >translated to the POSIX EIO.  Another chance to get EIO is if something
> >goes badly wrong trying to read a symlink.  Or, that's always a chance,
> >the OSX smb server doesn't support some system call used by Cygwin.  It
> >wouldn't be the first such FS.
> 
> You must be Santa!
> 
> I did not believe it, but I tried the same share names on a linux server: 
> that works fine.
> 
> Indeed it looks like a cygwin/mac problem.
> That still leaves me with a lot of unhappy users.
> 
> So where can I find strace?

In /bin.


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

Best practice for running pgsql under cygwin?

2012-12-21 Thread Ryan Johnson


Hi all,

I'm trying to set up pgsql for classroom instruction, which means I need 
to allow students to connect to my machine, preferably with no OS-level 
privileges and minimal database privileges. Setting up the database 
roles looks straightforward enough, but I'm having trouble figuring out 
how to secure the machine. In particular, the advice to run pgsql as an 
unprivileged user seems very good, but all the official docs I can find 
for doing so require su/sudo and useradd. Installing pgsql as a service 
using the script in /etc/rc.d runs it as the SYSTEM user, which is 
anything but unprivileged [1][2]; it seems like the LocalService or 
NetworkService account [3] would be a much better choice.


The pgsql README in /usr/doc/cygwin contains no useful information on 
the topic; there are lots of third-party pages offering "helpful" advice 
for cygwin+pgsql, but we all know how reliable those are (especially 
since the most recent one I can find dates from 2008).


Does anybody have some advice on how I might proceed? Note that I don't 
actually need it to run as a Windows service, it's just that most docs I 
can find seem to point that way. If it would be better to create a pgsql 
account (perhaps with help from cygwin-service-installation-helper.sh), 
I'd be happy to go that way as well.


Thanks in advance,
Ryan

[1] http://support.microsoft.com/kb/120929
[2] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms684190%28v=vs.85%29.aspx
[3] 
http://msdn.microsoft.com/en-us/library/windows/desktop/ms686005%28v=vs.85%29.aspx




--
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: trouble accessing samba shares with spaces and/or parentheses


On 12/21/2012 06:19 PM, Corinna Vinschen wrote:

On Dec 21 18:01, bartels wrote:

On 12/21/2012 05:47 PM, Corinna Vinschen wrote:

On Dec 21 17:20, bartels wrote:

$ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels" 
/user:"bartels"
The command completed successfully.

$ ls q:/
ls: cannot access q:/: Input/output error

Please don't use DOS paths.  Use POSIX paths like /cygdrive/q instead:
http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32

Naturally, I tried all flavours:

$ ls /cygdrive/q/
ls: cannot access /cygdrive/q/: Input/output error




Works fine for me using a Linux Samba share with space in it.

Okay, that leaves the parentheses as the likely troublemaker.
The thing is, people bring in disks, and I have no control over their volume / 
share names.

Any more ideas? Where's Santa when you need him ;-)

"Input/output error" is just an EIO.  strace might show more useful
information.  EIO could be generated for a couple of reasons, for
instance, the WIn32 errors ERROR_DISK_CORRUPT or ERROR_OPEN_FAILED are
translated to the POSIX EIO.  Another chance to get EIO is if something
goes badly wrong trying to read a symlink.  Or, that's always a chance,
the OSX smb server doesn't support some system call used by Cygwin.  It
wouldn't be the first such FS.


You must be Santa!

I did not believe it, but I tried the same share names on a linux server: that 
works fine.

Indeed it looks like a cygwin/mac problem.
That still leaves me with a lot of unhappy users.

So where can I find strace?

- bartels



--
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: X windows problems

2012-12-21 Thread George Barrick

Re: X windows problems

 2012.12.21.17:22:36 UT

Hi Ryan,

  The UAC basically just irritates the
snot out of me.  When I run a cmd-line line
program, I just hate having to go through a
three-click process to confirm that I _am_
the authorized user of the computer.

 I realize that I am taking risks by
disabling UAC, but I do not care.  UAC sucks.

George gbarrick_at_walsh_dot_edu



--
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: trouble accessing samba shares with spaces and/or parentheses

On Dec 21 18:01, bartels wrote:
> On 12/21/2012 05:47 PM, Corinna Vinschen wrote:
> >On Dec 21 17:20, bartels wrote:
> >>$ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels" 
> >>/user:"bartels"
> >>The command completed successfully.
> >>
> >>$ ls q:/
> >>ls: cannot access q:/: Input/output error
> >Please don't use DOS paths.  Use POSIX paths like /cygdrive/q instead:
> >http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32
> 
> Naturally, I tried all flavours:
> 
> $ ls /cygdrive/q/
> ls: cannot access /cygdrive/q/: Input/output error
> 
> 
> 
> >Works fine for me using a Linux Samba share with space in it.
> 
> Okay, that leaves the parentheses as the likely troublemaker.
> The thing is, people bring in disks, and I have no control over their volume 
> / share names.
> 
> Any more ideas? Where's Santa when you need him ;-)

"Input/output error" is just an EIO.  strace might show more useful
information.  EIO could be generated for a couple of reasons, for
instance, the WIn32 errors ERROR_DISK_CORRUPT or ERROR_OPEN_FAILED are
translated to the POSIX EIO.  Another chance to get EIO is if something
goes badly wrong trying to read a symlink.  Or, that's always a chance,
the OSX smb server doesn't support some system call used by Cygwin.  It
wouldn't be the first such FS.


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

Re: trouble accessing samba shares with spaces and/or parentheses

2012-12-21 Thread René Berber


On 12/21/2012 11:15 AM, marco atzeri wrote:

[snip]

it should be the usual "\"

ls "//macau/X32\ Backup-4\(WD\)/"


Without the quotes:

$ ls //HPMediaVault/Backup
X32 Backup-4(WD)/

$ ll //HPMediaVault/Backup/X32\ Backup-4\(WD\)/
total 0
drwxrwxrwx 1    Unix Group\nobody 0 Dec 21 11:15 ./
drwxrwxrwx 1 Unix User\root Unix Group\root   0 Dec 21 11:15 ../

--
René Berber


--
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: trouble accessing samba shares with spaces and/or parentheses

2012-12-21 Thread marco atzeri


On 12/21/2012 6:11 PM, bartels wrote:


Just did that. Same difference:

$ ls "//macau/X32 Backup-4(WD)/"
ls: cannot access //macau/X32 Backup-4(WD)/: Input/output error


Is there a set of escape characters for spaces, parens and whatnot?

- bartels



it should be the usual "\"

ls "//macau/X32\ Backup-4\(WD\)/"


Marco


--
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: trouble accessing samba shares with spaces and/or parentheses


On 12/21/2012 05:47 PM, René Berber wrote:

On 12/21/2012 10:20 AM, bartels wrote:

[snip]

$ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels"
/user:"bartels"
The command completed successfully.

$ ls q:/
ls: cannot access q:/: Input/output error


Have you tried the correct way? ls /cygdrive/q


Did actually. No difference.
The bugger is mounted, that is the strange part:


$ net use
New connections will be remembered.


Status   Local RemoteNetwork

---
OK   Q:\\macau\X32 Backup-4(WD)
Microsoft Windows Network



or the alternative Network share way? ls "//macau/X32 Backup-4(WD)"


Just did that. Same difference:

$ ls "//macau/X32 Backup-4(WD)/"
ls: cannot access //macau/X32 Backup-4(WD)/: Input/output error


Is there a set of escape characters for spaces, parens and whatnot?

- bartels




--
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

On Dec 21 11:10, Christopher Faylor wrote:
> On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
> >Maybe the signal thread should really not exit by itself, but just
> >wait until the TerminateThread is called.  Chris?
> 
> If the analysis is correct, that just fixes one symptom doesn't it?
> There are potentially many threads running in any Cygwin program
> and it sounds like any one of them could trigger this.

Right.  I guess the question is how to synchronize things so that the
thread calling TerminateProcess is actually the last one, making sure
its return value is used.

Maybe the NtQueryInformationThread(ThreadAmILastThread) call is of some
help.  Or we have to keep all thread IDs of the self-started threads
available to terminate them explicitely at process exit.

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

Re: trouble accessing samba shares with spaces and/or parentheses


On 12/21/2012 05:47 PM, Corinna Vinschen wrote:

On Dec 21 17:20, bartels wrote:

$ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels" 
/user:"bartels"
The command completed successfully.

$ ls q:/
ls: cannot access q:/: Input/output error

Please don't use DOS paths.  Use POSIX paths like /cygdrive/q instead:
http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32


Naturally, I tried all flavours:

$ ls /cygdrive/q/
ls: cannot access /cygdrive/q/: Input/output error




Works fine for me using a Linux Samba share with space in it.


Okay, that leaves the parentheses as the likely troublemaker.
The thing is, people bring in disks, and I have no control over their volume / 
share names.

Any more ideas? Where's Santa when you need him ;-)


- bartels

--
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: trouble accessing samba shares with spaces and/or parentheses

On Dec 21 17:20, bartels wrote:
> Hello Cygwin,
> 
> I am experiencing problems with spaces and/or parentheses in samba share 
> names.
> Changing the share name is not an option, because they are physical drives, 
> connected to a mac.
> 
> The following works fine from a dos box, and also from the gui with 'Map 
> network drive', but fails miserably from the cygwin prompt.
> 
> $ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels" 
> /user:"bartels"
> The command completed successfully.
> 
> $ ls q:/
> ls: cannot access q:/: Input/output error

Please don't use DOS paths.  Use POSIX paths like /cygdrive/q instead:
http://cygwin.com/cygwin-ug-net/using.html#pathnames-win32

> This is not a question of privileges or configuration: other shares with 
> vanilla names work fine.
> The mac logs do not immediately reveal any clues.
> Considering that the dos box and the gui have access, I am inclined to blame 
> cygwin.
> 
> Any ideas?

Works fine for me using a Linux Samba share with space in it.


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

Re: trouble accessing samba shares with spaces and/or parentheses

2012-12-21 Thread René Berber


On 12/21/2012 10:20 AM, bartels wrote:

[snip]

$ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels"
/user:"bartels"
The command completed successfully.

$ ls q:/
ls: cannot access q:/: Input/output error


Have you tried the correct way? ls /cygdrive/q

or the alternative Network share way? ls "//macau/X32 Backup-4(WD)"
--
René Berber


--
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

trouble accessing samba shares with spaces and/or parentheses


Hello Cygwin,

I am experiencing problems with spaces and/or parentheses in samba share names.
Changing the share name is not an option, because they are physical drives, 
connected to a mac.

The following works fine from a dos box, and also from the gui with 'Map 
network drive', but fails miserably from the cygwin prompt.

$ net use Q: "$(cygpath -w '//macau/X32 Backup-4(WD)')" "bartels" 
/user:"bartels"
The command completed successfully.

$ ls q:/
ls: cannot access q:/: Input/output error


This is not a question of privileges or configuration: other shares with 
vanilla names work fine.
The mac logs do not immediately reveal any clues.
Considering that the dos box and the gui have access, I am inclined to blame 
cygwin.

Any ideas?

Thanks
- bartels




--
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

On Fri, Dec 21, 2012 at 11:32:41AM +0100, Corinna Vinschen wrote:
>Maybe the signal thread should really not exit by itself, but just
>wait until the TerminateThread is called.  Chris?

If the analysis is correct, that just fixes one symptom doesn't it?
There are potentially many threads running in any Cygwin program
and it sounds like any one of them could trigger this.

cgf

--
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

2012-12-21 Thread Nick Lowe

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