This is the mail archive of the cygwin mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: directory listing differences


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/


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]