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
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/
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: registry's role, or must I install on client madhines
Christopher Faylor wrote: On Wed, May 23, 2007 at 10:00:49AM -0400, Joseph Michaud wrote: I have cygwin installed on a Windows share. I'm trying to use it from another Windows client machine (on which it was never installed) by simply running the bash executable using the UNC path (//share/cygwin/bin/bash.exe -l -i). This isn't working. ... The only other thing I can think of is that the registry is being set up when you do an install and that these registry entries are required when bash is invoked. Are registry entries referenced when running bash? Cygwin, (somewhat) like linux, sets up a mount table which creates a root directory, bin directory and other directories. You can see what's created by typing mount. The fact that this information is stored in the registry is irrelevant (and WILL change eventually). You should use the mount command to see how things are set up. Is it possible to setup cygwin so that it may be used from a share without having been installed on the client machine? Possibly. You don't absolutely need the mount table (with the possible exception of /tmp) but, if you want to have bash set things up automatically, you will need to investigate how bash works, set the appropriate environment variables, and use the appropriate command line switches. info bash may help. Also check out man mount paying particular attention to mount -m. Bingo! That's the trick. As soon as I ran the appropriate mount commands on my client machines (specifying //share/cygwin...) everything worked. Thanks. 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/
registry's role, or must I install on client madhines
I have cygwin installed on a Windows share. I'm trying to use it from another Windows client machine (on which it was never installed) by simply running the bash executable using the UNC path (//share/cygwin/bin/bash.exe -l -i). This isn't working. I've tried a number of variations like: where my current working directory is (local or remote); starting bash in a local directory and then starting in the remote directory; trying various CYGWIN variables. In all cases the resulting environment for bash has a variety of problems, likely stemming from the fact that HOME and PATH do not get set up. No /etc/profile or .bashrc are processed. 'cd' works but only by using relative paths (../foo) but not absolute paths (/foo). I *can* see the filesystem (with echo * or something like ../bin/ls). I've also tried setting up the Windows client machine to map a network drive so that the client machine has the same drive letter and directory structure as the master machine (ie, G:/cygwin). No joy. I had wanted to avoid installing cygwin on all the client machines but this is beginning to seem less possible. The only other thing I can think of is that the registry is being set up when you do an install and that these registry entries are required when bash is invoked. Are registry entries referenced when running bash? Is it possible to setup cygwin so that it may be used from a share without having been installed on the client machine? 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/
