On 23 October 2007 17:02, Joseph Michaud wrote:
> Just to follow-up on this...
>
> I recently came back to this problem. Dave's suggestion to use Process
> Explorer was useful in that it showed that bash was using some SysWOW64
> DLLS. This reminded me that 64-bit Windows transparently redirect
On 07 June 2007 17:03, Dave Korn wrote:
On 07 June 2007 16:46, Joseph Michaud wrote:
One interesting tidbit is that if, from the bash shell, I invoke
a Windows CMD shell, then that CMD shell similarly doesn't see the
file.
I conclude from this that somehow the bash shell doesn't have
some app
On 07 June 2007 16:46, Joseph Michaud wrote:
> One interesting tidbit is that if, from the bash shell, I invoke
> a Windows CMD shell, then that CMD shell similarly doesn't see the
> file.
>
> I conclude from this that somehow the bash shell doesn't have
> some appropriate privilege and that bas
Shankar Unni wrote:
Joseph Michaud wrote:
[EMAIL PROTECTED] /cygdrive/c/windows/system32
$ ls -al tsdiscon.exe tsecimp.exe
ls: cannot access tsdiscon.exe: No such file or directory
That's probably because the file is exclusively locked, and the "stat" performed by
"ls"
Joseph Michaud wrote:
[EMAIL PROTECTED] /cygdrive/c/windows/system32
$ ls -al tsdiscon.exe tsecimp.exe
ls: cannot access tsdiscon.exe: No such file or directory
That's probably because the file is exclusively locked, and the "stat"
performed by "ls" fails.
See if you see the file if you pas
I noticed the following problem because c:\windows\system32\telnet.exe
was one of the files affected...
A directory listing shows different files if I compare the windows
DIR command to the cygwin "ls". For example, I look in
c:\windows\system32 for two files (tsdiscon.exe and tsecimp.exe)
using
6 matches
Mail list logo
