"dir" shows different results in cmd vs. 4NT

  • Thread starter Thread starter Guest
  • Start date Start date
G

Guest

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.
 
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.
 
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\System32>icacls bcdedit.exe
bcdedit.exe NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)

Successfully processed 1 files; Failed processing 0 files

C:\Windows\System32>icacls bcrypt.dll
bcrypt.dll NT SERVICE\TrustedInstaller:(F)
BUILTIN\Administrators:(RX)
NT AUTHORITY\SYSTEM:(RX)
BUILTIN\Users:(RX)

Successfully processed 1 files; Failed processing 0 files


Any other ideas?

Keith
 
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:
Click to expand...

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.
 
Jesper said:
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.
Click to expand...

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?
Click to expand...

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.
Click to expand...

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
 
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?
 
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
 
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
 
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.
 
Back
Top