Message-ID: <471E1B0E.3070704@sgi.com>
Date: Tue, 23 Oct 2007 12:02:22 -0400
From: Joseph Michaud <jmichaud AT sgi DOT com>
User-Agent: Thunderbird 2.0.0.6 (Windows/20070728)
MIME-Version: 1.0
To: cygwin AT cygwin DOT com
Subject: Re: directory listing differences
References: <46682824 DOT 9070507 AT sgi DOT com>
In-Reply-To: <46682824.9070507@sgi.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit
Mailing-List: contact cygwin-help AT cygwin DOT com; run by ezmlm
Sender: cygwin-owner AT cygwin DOT com
Mail-Followup-To: cygwin AT cygwin DOT com

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 appropriate privilege and that bash's children similarly
>> lack this privilege, but I can't figure out why two files with
>> seemingly similar permissions are different.
> 
>   To processes with different access tokens, "seemingly" similar permissions
> aren't.  As a simple example, consider a file with "rwxr-x---" perms.  Your
> access perms will be very different if you are logged in as the user who owns
> the file compared with if you log in as a different user in the file's group
> as compared to if you log in as another user who isn't in that group at
> all....
>  
>> I note that I see this problem on a Windows 2003 Compute Cluster Server
>> domain controller head node (and its compute nodes) but not
>> not on a Windows XP 64 laptop.  (Perhaps something with domain
>> controller security policy is affecting this...)
> 
>   Almost certainly so.
>  
>> Any tips on what other info I can look for would help.
> 
>   Use Process Explorer to look at the tokens of the two different processes
> (cmd launched by itself, cmd launched from bash) and see what's different.
> 

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 redirects
32-bit apps from \Windows\system32 to \Windows\SysWOW64.

The issue has nothing to do with permissions.  Because bash is a 32-bit
app, when it tries to look in \Windows\system32, the OS redirects that
request to show instead \Windows\SysWOW64.  There is a (64-bit)
telnet.exe in system32 but no (32-bit) telnet.exe in SysWOW64.

I introduced a red herring when I noted that a cmd.exe invoked from
bash also exhibited the "inability" to list system32\telnet.exe.
This is because a 32-bit bash will (by default) launch a 32-bit
cmd.exe and, similarly, the attempt to view system32 from a 32-bit
cmd.exe is transparently redirected to SysWOW64.

You would think that to work around this you could use the
64-bit cmd.exe from bash by invoking via the absolute path
C:\Windows\system32\cmd.exe but the OS catches this too and
you still end up with the 32-bit cmd.exe.


You *can* fake out the OS by creating a substitute drive
and access system32 that way

   subst x: c:\
   dir x:\windows\system32\telnet.exe


Or, from bash, you could use the UNC paths for the C drive like so

   ls //<machine_name>/c$/WINDOWS/system32/telnet.exe


Reference the following threads:

    9-Jan-06  Cygwin cannot find certain files under Windows 2003
    7-Jun-07  Certain files in the system32 directory are not listed

Joe


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/