Welcome to Vista Banter. You are currently viewing our boards as a guest which gives you limited access to view most discussions, articles and access our other FREE features. By joining our free community you will have access to ask questions and reply to others posts, upload your own photos and access many other special features. Registration is fast, simple and absolutely free so please, join our community today! If you have any problems with the registration process or your account login, please contact contact support. |
|
Security and Windows Vista A forum for discussion on security issues with Windows Vista. (microsoft.public.windows.vista.security) |
|
LinkBack | Thread Tools | Display Modes |
|
|||
"dir" shows different results in cmd vs. 4NT
I'm sure there's some simple explanation for this, but I'm currently stumped.
If I open a command prompt (cmd.exe) and type "dir c:\windows\system32" in my Vista Ultimate x64 install, it shows that I have roughly 2300 files there. However, if I open a 4NT window (an alternate command shell by JPSoft Inc.) -- whether it's as myself or when choosing "Run as administrator" -- and type the same command, it only sees about 1900 files. One example of a discrepancy: bcdedit. I can run it fine from the cmd window, but in 4NT, it believes the file does not exist. This reproduces with the latest version of 4NT, which purports to fully support Vista, too. The files that are not displaying are not hidden, are not system files, and as far as I can tell, have the same permissions as those that are being shown. Even more confusing: if I use an old "ls" binary from some Unix utilities distribution built years ago, it shows about 2050 files in that directory! What is so special about some of the files in this directory that would prevent a different shell or a different cmdline program like ls from seeing them? Is there some special Vista security feature or new NTFS extension that's hiding them from anything other than cmd or explorer? Does it have something to do with the fact that this is a 64-bit install, but these programs are 32-bit? (I would note, however, that I can consistently see all the files using any tool if I look at the directory from an XP install on the same machine.) I'm stumped! Thanks in advance. |
|
|||
"dir" shows different results in cmd vs. 4NT
My guess is that some of your "Files" are "Junctions" and the phenomenon is
due to the fact that Vista uses these "Junctions" to point to files that are really somewhere else. There's a whole lot of stuff here http://msdn2.microsoft.com/en-us/library/aa480152.aspx or you could just Google "Vista Junction" for more general views. Charlie "Keith S." wrote in message ... I'm sure there's some simple explanation for this, but I'm currently stumped. If I open a command prompt (cmd.exe) and type "dir c:\windows\system32" in my Vista Ultimate x64 install, it shows that I have roughly 2300 files there. However, if I open a 4NT window (an alternate command shell by JPSoft Inc.) -- whether it's as myself or when choosing "Run as administrator" -- and type the same command, it only sees about 1900 files. One example of a discrepancy: bcdedit. I can run it fine from the cmd window, but in 4NT, it believes the file does not exist. This reproduces with the latest version of 4NT, which purports to fully support Vista, too. The files that are not displaying are not hidden, are not system files, and as far as I can tell, have the same permissions as those that are being shown. Even more confusing: if I use an old "ls" binary from some Unix utilities distribution built years ago, it shows about 2050 files in that directory! What is so special about some of the files in this directory that would prevent a different shell or a different cmdline program like ls from seeing them? Is there some special Vista security feature or new NTFS extension that's hiding them from anything other than cmd or explorer? Does it have something to do with the fact that this is a 64-bit install, but these programs are 32-bit? (I would note, however, that I can consistently see all the files using any tool if I look at the directory from an XP install on the same machine.) I'm stumped! Thanks in advance. |
|
|||
"dir" shows different results in cmd vs. 4NT
It could be ACLs, or it could be that 4NT has not been updated to support
symlinks properly. It's hard to tell without having more details on exactly which files are failing and their ACLs. I'd consider cmd as authoritative. If you send icalcs output on a file that is showing in 4nt and one that is not, that would be helpful. "Keith S." wrote: I'm sure there's some simple explanation for this, but I'm currently stumped. If I open a command prompt (cmd.exe) and type "dir c:\windows\system32" in my Vista Ultimate x64 install, it shows that I have roughly 2300 files there. However, if I open a 4NT window (an alternate command shell by JPSoft Inc.) -- whether it's as myself or when choosing "Run as administrator" -- and type the same command, it only sees about 1900 files. One example of a discrepancy: bcdedit. I can run it fine from the cmd window, but in 4NT, it believes the file does not exist. This reproduces with the latest version of 4NT, which purports to fully support Vista, too. The files that are not displaying are not hidden, are not system files, and as far as I can tell, have the same permissions as those that are being shown. Even more confusing: if I use an old "ls" binary from some Unix utilities distribution built years ago, it shows about 2050 files in that directory! What is so special about some of the files in this directory that would prevent a different shell or a different cmdline program like ls from seeing them? Is there some special Vista security feature or new NTFS extension that's hiding them from anything other than cmd or explorer? Does it have something to do with the fact that this is a 64-bit install, but these programs are 32-bit? (I would note, however, that I can consistently see all the files using any tool if I look at the directory from an XP install on the same machine.) I'm stumped! Thanks in advance. |
|
|||
"dir" shows different results in cmd vs. 4NT
It's not symlinks, that I know. 4NT does support them, and displays them with
SYMLINK in the directory listing. And if it's ACLs, it's something not readily transparent to me (see below). Here's an example that narrows it down. In the Windows\system32 directory, do "dir bc*". cmd shows four files; 4NT only shows bcrypt.dll. The icacls output on both bcrypt.dll and bcdedit.exe (which does not show up in 4NT) is identical: C:\Windows\System32icacls bcdedit.exe bcdedit.exe NT SERVICE\TrustedInstallerF) BUILTIN\AdministratorsRX) NT AUTHORITY\SYSTEMRX) BUILTIN\UsersRX) Successfully processed 1 files; Failed processing 0 files C:\Windows\System32icacls bcrypt.dll bcrypt.dll NT SERVICE\TrustedInstallerF) BUILTIN\AdministratorsRX) NT AUTHORITY\SYSTEMRX) BUILTIN\UsersRX) Successfully processed 1 files; Failed processing 0 files Any other ideas? Keith "Jesper" wrote: It could be ACLs, or it could be that 4NT has not been updated to support symlinks properly. It's hard to tell without having more details on exactly which files are failing and their ACLs. I'd consider cmd as authoritative. If you send icalcs output on a file that is showing in 4nt and one that is not, that would be helpful. "Keith S." wrote: I'm sure there's some simple explanation for this, but I'm currently stumped. If I open a command prompt (cmd.exe) and type "dir c:\windows\system32" in my Vista Ultimate x64 install, it shows that I have roughly 2300 files there. However, if I open a 4NT window (an alternate command shell by JPSoft Inc.) -- whether it's as myself or when choosing "Run as administrator" -- and type the same command, it only sees about 1900 files. One example of a discrepancy: bcdedit. I can run it fine from the cmd window, but in 4NT, it believes the file does not exist. This reproduces with the latest version of 4NT, which purports to fully support Vista, too. ... |
|
|||
"dir" shows different results in cmd vs. 4NT
Here's an example that narrows it down. In the Windows\system32 directory,
do "dir bc*". cmd shows four files; 4NT only shows bcrypt.dll. The icacls output on both bcrypt.dll and bcdedit.exe (which does not show up in 4NT) is identical: They sure look identical. Why don't you use the save switch on icacls to save the actual SDDL. If it is something ACL-related that would show it. You said the file attributes are the same? IIRC, 4NT has a /a switch as well, but you are using that right? Are you running these commands from an elevated command prompt? 4NT and cmd.exe should both be using the same set of APIs, so there should be no difference. I may have to grab a copy of 4NT so I can see this for myself. |
|
|||
"dir" shows different results in cmd vs. 4NT
"Jesper" wrote:
Here's an example that narrows it down. In the Windows\system32 directory, do "dir bc*". cmd shows four files; 4NT only shows bcrypt.dll. The icacls output on both bcrypt.dll and bcdedit.exe (which does not show up in 4NT) is identical: They sure look identical. Why don't you use the save switch on icacls to save the actual SDDL. If it is something ACL-related that would show it. Done -- and yes, they're exactly the same. You said the file attributes are the same? IIRC, 4NT has a /a switch as well, but you are using that right? Are you running these commands from an elevated command prompt? I've tested running 4NT as administrator, and as myself, and the results are the same. I wasn't running cmd as administrator, strange enough. I also verified using the /A: switch with 4NT, but that made no difference. 4NT and cmd.exe should both be using the same set of APIs, so there should be no difference. I may have to grab a copy of 4NT so I can see this for myself. Thanks. Any extra eyes would be a welcome thing, at this point. It can be found at http://www.jpsoft.com/download.htm . I also have a single "ls" binary, if you want to test with that, too, which I can easily make available for download from my website. (To make matters worse, the results of ls are different from both cmd *and* 4NT.) Keith |
|
|||
"dir" shows different results in cmd vs. 4NT
I'm at a loss here. I do get different results from ksh and cmd, but they are
nowhere near as drastic as what you are seeing. It has to be something 64-bit related. Have you talked to the author of 4NT about this? "Keith S." wrote: "Jesper" wrote: Here's an example that narrows it down. In the Windows\system32 directory, do "dir bc*". cmd shows four files; 4NT only shows bcrypt.dll. The icacls output on both bcrypt.dll and bcdedit.exe (which does not show up in 4NT) is identical: They sure look identical. Why don't you use the save switch on icacls to save the actual SDDL. If it is something ACL-related that would show it. Done -- and yes, they're exactly the same. You said the file attributes are the same? IIRC, 4NT has a /a switch as well, but you are using that right? Are you running these commands from an elevated command prompt? I've tested running 4NT as administrator, and as myself, and the results are the same. I wasn't running cmd as administrator, strange enough. I also verified using the /A: switch with 4NT, but that made no difference. 4NT and cmd.exe should both be using the same set of APIs, so there should be no difference. I may have to grab a copy of 4NT so I can see this for myself. Thanks. Any extra eyes would be a welcome thing, at this point. It can be found at http://www.jpsoft.com/download.htm . I also have a single "ls" binary, if you want to test with that, too, which I can easily make available for download from my website. (To make matters worse, the results of ls are different from both cmd *and* 4NT.) Keith |
|
|||
"dir" shows different results in cmd vs. 4NT
I haven't spoken to JPSoft (makers of 4NT) yet, mainly because I was trying
to determine whether it was a problem (or just a difference) with Vista, either configuration or feature-related. However, testing with ksh has added yet another variable to the mix. So with at least three different tools (ksh, 4NT, and a gcc-built ls), we have different results. Doesn't sound like something 4NT is doing wrong, really, if everyone is coming up with different results. It would be great if someone could compare results in a 32-bit Vista install to see if it really was due to the 64-bit version. Although I can't imagine any scenario whereby a 64-bit compiled program would appear differently in a directory listing as a 32-bit compiled program. Shouldn't make a difference. To be honest, not knowing what is causing this is making me wonder whether I go back to using the 32-bit install. Mind you, inability to see consistent directory results using 4NT isn't a showstopper by any means; my main concern is that without knowing why this is happening, it could just be the "tip of the iceberg", and just one of many cases where this type of behavior will crop up. I'll try pinging JPSoft next. Thanks for your help, Keith "Jesper" wrote: I'm at a loss here. I do get different results from ksh and cmd, but they are nowhere near as drastic as what you are seeing. It has to be something 64-bit related. Have you talked to the author of 4NT about this? "Keith S." wrote: "Jesper" wrote: Here's an example that narrows it down. In the Windows\system32 directory, do "dir bc*". cmd shows four files; 4NT only shows bcrypt.dll. The icacls output on both bcrypt.dll and bcdedit.exe (which does not show up in 4NT) is identical: They sure look identical. Why don't you use the save switch on icacls to save the actual SDDL. If it is something ACL-related that would show it. Done -- and yes, they're exactly the same. You said the file attributes are the same? IIRC, 4NT has a /a switch as well, but you are using that right? Are you running these commands from an elevated command prompt? I've tested running 4NT as administrator, and as myself, and the results are the same. I wasn't running cmd as administrator, strange enough. I also verified using the /A: switch with 4NT, but that made no difference. 4NT and cmd.exe should both be using the same set of APIs, so there should be no difference. I may have to grab a copy of 4NT so I can see this for myself. Thanks. Any extra eyes would be a welcome thing, at this point. It can be found at http://www.jpsoft.com/download.htm . I also have a single "ls" binary, if you want to test with that, too, which I can easily make available for download from my website. (To make matters worse, the results of ls are different from both cmd *and* 4NT.) Keith |
|
|||
SOLUTION: "dir" shows different results in cmd vs. 4NT
Okay, I figured out what was going on with 4NT. Still no explanation for ls
or ksh, but... In a 64-bit OS, 4NT automatically redirects all calls to the \windows\syswow64 directory -- even a dir listing (which I think is a bug). By adding the line "WOW64FSRedirection=No" to the 4NT.ini file, the directory command now works (and I can run bcdedit). I'm not sure what other side effects would come from this, but it at least explains what was happening. Whew! Not a Vista issue after all. Keith "Keith S." wrote: "Jesper" wrote: I'm at a loss here. I do get different results from ksh and cmd, but they are nowhere near as drastic as what you are seeing. It has to be something 64-bit related. Have you talked to the author of 4NT about this? "Keith S." wrote: "Jesper" wrote: Here's an example that narrows it down. In the Windows\system32 directory, do "dir bc*". cmd shows four files; 4NT only shows bcrypt.dll. The icacls output on both bcrypt.dll and bcdedit.exe (which does not show up in 4NT) is identical: They sure look identical. Why don't you use the save switch on icacls to save the actual SDDL. If it is something ACL-related that would show it. Done -- and yes, they're exactly the same. You said the file attributes are the same? IIRC, 4NT has a /a switch as well, but you are using that right? Are you running these commands from an elevated command prompt? I've tested running 4NT as administrator, and as myself, and the results are the same. I wasn't running cmd as administrator, strange enough. I also verified using the /A: switch with 4NT, but that made no difference. 4NT and cmd.exe should both be using the same set of APIs, so there should be no difference. I may have to grab a copy of 4NT so I can see this for myself. Thanks. Any extra eyes would be a welcome thing, at this point. It can be found at http://www.jpsoft.com/download.htm . I also have a single "ls" binary, if you want to test with that, too, which I can easily make available for download from my website. (To make matters worse, the results of ls are different from both cmd *and* 4NT.) Keith |
|
|||
SOLUTION: "dir" shows different results in cmd vs. 4NT
Aah. That makes sense. With ksh the issue is that there are files that are
hidden from CMD. I think these may be the "superhidden" files, like 7B296FB0-376B-497e-B012-9C450E1B7327-2P-1.C7483456-A289-439d-8115-601632D005A0. The difference is only 5 files. It is not nearly as drastic as with 4NT. Sounds like you figured it out all on your own. "Keith S." wrote: Okay, I figured out what was going on with 4NT. Still no explanation for ls or ksh, but... In a 64-bit OS, 4NT automatically redirects all calls to the \windows\syswow64 directory -- even a dir listing (which I think is a bug). By adding the line "WOW64FSRedirection=No" to the 4NT.ini file, the directory command now works (and I can run bcdedit). I'm not sure what other side effects would come from this, but it at least explains what was happening. Whew! Not a Vista issue after all. Keith "Keith S." wrote: "Jesper" wrote: I'm at a loss here. I do get different results from ksh and cmd, but they are nowhere near as drastic as what you are seeing. It has to be something 64-bit related. Have you talked to the author of 4NT about this? "Keith S." wrote: "Jesper" wrote: Here's an example that narrows it down. In the Windows\system32 directory, do "dir bc*". cmd shows four files; 4NT only shows bcrypt.dll. The icacls output on both bcrypt.dll and bcdedit.exe (which does not show up in 4NT) is identical: They sure look identical. Why don't you use the save switch on icacls to save the actual SDDL. If it is something ACL-related that would show it. Done -- and yes, they're exactly the same. You said the file attributes are the same? IIRC, 4NT has a /a switch as well, but you are using that right? Are you running these commands from an elevated command prompt? I've tested running 4NT as administrator, and as myself, and the results are the same. I wasn't running cmd as administrator, strange enough. I also verified using the /A: switch with 4NT, but that made no difference. 4NT and cmd.exe should both be using the same set of APIs, so there should be no difference. I may have to grab a copy of 4NT so I can see this for myself. Thanks. Any extra eyes would be a welcome thing, at this point. It can be found at http://www.jpsoft.com/download.htm . I also have a single "ls" binary, if you want to test with that, too, which I can easily make available for download from my website. (To make matters worse, the results of ls are different from both cmd *and* 4NT.) Keith |