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/
RE: directory listing differences
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 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. D'oh! D'oh! D'oh! foreheadslap I should have remembered that. See the thread Certain files in the system32 directory are not listed at http://www.cygwin.com/ml/cygwin/2007-06/threads.html#00110 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 Ah, I see you already did! But see also http://cygwin.com/ml/cygwin-talk/2007-q2/msg00168.html where I posted the simplest possible explanation of the whole sorry mess... cheers, DaveK -- Can't think of a witty .sigline today -- 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/
Re: directory listing differences
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 fails. See if you see the file if you pass in the -f option to ls: $ ls -f tsdiscon.exe tsecimp.exe If you can, then this is the issue. Looks like CMD.EXE is able to examine whatever it needs from such files, but stat() in the cygwin library cannot (uses different APIs). I see similar behavior in a file that PointSec drops in my C:\\ (PROT_INS.SYS). In fact, even ls -f is not able to get any info on that file! % cmd /c dir /AH c:\\prot_ins.sys Volume in drive C has no label. Volume Serial Number is A8B1-8402 Directory of c:\ 03/22/2007 11:03 AM 2,097,152 PROT_INS.SYS 1 File(s) 2,097,152 bytes 0 Dir(s) 4,296,351,744 bytes free % ls -ln c:\\prot_ins.sys ls: cannot access c:\prot_ins.sys: Input/Output error % ls -f c:\\prot_ins.sys ls: cannot access c:\prot_ins.sys: Input/Output error Nope, that's not quite it for me. I try ls -f but still don't see the file. 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. 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...) Any tips on what other info I can look for would help. Thanks. Joe -- Joseph Michaud - SGI Apps Eng 978-562-8808 x483-8808 [EMAIL PROTECTED] -- 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/
RE: directory listing differences
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. cheers, DaveK -- Can't think of a witty .sigline today -- 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/
directory listing differences
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 both the windows DIR command in a CMD shell and ls in a bash shell. tsdiscon.exe is missing under cygwin. C:\WINDOWS\system32 C:\WINDOWS\system32dir /q tsdiscon.exe tsecimp.exe Volume in drive C has no label. Volume Serial Number is 2857-9183 Directory of C:\WINDOWS\system32 02/18/2007 05:00 AM24,064 BUILTIN\Administrators tsdiscon.exe Directory of C:\WINDOWS\system32 02/18/2007 05:00 AM38,400 BUILTIN\Administrators tsecimp.exe 2 File(s) 62,464 bytes 0 Dir(s) 132,988,616,704 bytes free C:\WINDOWS\system32 C:\WINDOWS\system32 [EMAIL PROTECTED] /cygdrive/c/windows/system32 $ ls -al tsdiscon.exe tsecimp.exe ls: cannot access tsdiscon.exe: No such file or directory -rwxrwx--- 1 Administrators SYSTEM 26624 Feb 18 04:00 tsecimp.exe* $ The ACLs for the two files seem to be the same: C:\WINDOWS\system32cacls tsdiscon.exe C:\WINDOWS\system32\tsdiscon.exe NT AUTHORITY\INTERACTIVE:R NT AUTHORITY\SERVICE:R NT AUTHORITY\BATCH:R BUILTIN\Administrators:F NT AUTHORITY\SYSTEM:F BUILTIN\Administrators:F C:\WINDOWS\system32cacls tsecimp.exe C:\WINDOWS\system32\tsecimp.exe NT AUTHORITY\INTERACTIVE:R NT AUTHORITY\SERVICE:R NT AUTHORITY\BATCH:R BUILTIN\Administrators:F NT AUTHORITY\SYSTEM:F BUILTIN\Administrators:F C:\WINDOWS\system32 And here is the id for administrator under cygwin: [EMAIL PROTECTED] /cygdrive/c/windows/system32 $ id uid=500(Administrator) gid=513(Domain Users) groups=0(root),513(Domain Users),544(Administrators),554(Pre-Windows 2000 Compatible Ac cess),545(Users),1002(TelnetClients),10545(mkgroup_l_d) Any ideas? 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/
Re: directory listing differences
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 pass in the -f option to ls: $ ls -f tsdiscon.exe tsecimp.exe If you can, then this is the issue. Looks like CMD.EXE is able to examine whatever it needs from such files, but stat() in the cygwin library cannot (uses different APIs). I see similar behavior in a file that PointSec drops in my C:\\ (PROT_INS.SYS). In fact, even ls -f is not able to get any info on that file! % cmd /c dir /AH c:\\prot_ins.sys Volume in drive C has no label. Volume Serial Number is A8B1-8402 Directory of c:\ 03/22/2007 11:03 AM 2,097,152 PROT_INS.SYS 1 File(s) 2,097,152 bytes 0 Dir(s) 4,296,351,744 bytes free % ls -ln c:\\prot_ins.sys ls: cannot access c:\prot_ins.sys: Input/Output error % ls -f c:\\prot_ins.sys ls: cannot access c:\prot_ins.sys: Input/Output error -- 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/
