A Windows Vista forum. Vista Banter

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.

Go Back   Home » Vista Banter forum » Microsoft Windows Vista » Security and Windows Vista
Site Map Home Register Authors List Search Today's Posts Mark Forums Read Web Partners

Security and Windows Vista A forum for discussion on security issues with Windows Vista. (microsoft.public.windows.vista.security)

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



 
 
LinkBack Thread Tools Display Modes
  #1 (permalink)  
Old March 13th 07, 06:09 AM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Keith S.
external usenet poster
 
Posts: 11
Default "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.

  #2 (permalink)  
Old March 13th 07, 09:43 AM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Charlie Tame
external usenet poster
 
Posts: 2,383
Default "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.

  #3 (permalink)  
Old March 13th 07, 05:02 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Jesper
external usenet poster
 
Posts: 839
Default "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.

  #4 (permalink)  
Old March 13th 07, 06:49 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Keith S.
external usenet poster
 
Posts: 11
Default "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.
...


  #5 (permalink)  
Old March 13th 07, 08:11 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Jesper
external usenet poster
 
Posts: 839
Default "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.
  #6 (permalink)  
Old March 13th 07, 09:03 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Keith S.
external usenet poster
 
Posts: 11
Default "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

  #7 (permalink)  
Old March 14th 07, 06:21 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Jesper
external usenet poster
 
Posts: 839
Default "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

  #8 (permalink)  
Old March 14th 07, 07:06 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Keith S.
external usenet poster
 
Posts: 11
Default "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

  #9 (permalink)  
Old March 14th 07, 07:33 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Keith S.
external usenet poster
 
Posts: 11
Default 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

  #10 (permalink)  
Old March 14th 07, 08:51 PM posted to microsoft.public.windows.vista.file_management,microsoft.public.windows.vista.security
Jesper
external usenet poster
 
Posts: 839
Default 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

 




Thread Tools
Display Modes

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

vB code is On
Smilies are On
[IMG] code is On
HTML code is Off
Trackbacks are On
Pingbacks are On
Refbacks are On



All times are GMT. The time now is 09:01 AM.


Powered by vBulletin® Version 3.6.4
Copyright ©2000 - 2024, Jelsoft Enterprises Ltd.Search Engine Optimization by vBSEO 3.0.0 RC6
Copyright ©2004-2024 Vista Banter.
The comments are property of their posters.