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.

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." <(E-Mail Removed)> wrote in message
news:A04F874C-DB39-444A-85AF-(E-Mail Removed)...
> 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.

"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.
>

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\TrustedInstallerF)
BUILTIN\AdministratorsRX)
NT AUTHORITY\SYSTEMRX)
BUILTIN\UsersRX)

Successfully processed 1 files; Failed processing 0 files

C:\Windows\System32>icacls 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.
> > ...

> 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.

"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

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
>

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
> >

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
> > >

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
> > > >