Explorer Duplicate Listings

I post this every month or so to see if any new ideas or perspective.

There are 2 duplicate listings, each C:\Program Files\...

The 1st behaves normally but the 2nd is just a mirror image of the 1st
and it and nothing under it is accessable.

Any changes to the 1st are immediately reflected in the identical
mirror image 2nd.

Would like to eliminate the 2nd mirror image.

Ideas ?

SteveGG wrote:
I post this every month or so to see if any new ideas or perspective.

There are 2 duplicate listings, each C:\Program Files\...

The 1st behaves normally but the 2nd is just a mirror image of the 1st
and it and nothing under it is accessable.

Any changes to the 1st are immediately reflected in the identical
mirror image 2nd.

Would like to eliminate the 2nd mirror image.

Ideas ?

Post a picture of this duplicate listing.

http://postimage.org/index.php?um=flash

Test the "forum link" you get back, in a second
browser, to make sure it's viewable by everyone else.

Paul

Thanks Paul.

I hadn't dealt with Post Image before.

Very handy.

I think this is the gallery etc. :

https://postimg.org/gallery/iwnvo96e/

SteveGG wrote:
Thanks Paul.

I hadn't dealt with Post Image before.

Very handy.

I think this is the gallery etc. :

https://postimg.org/gallery/iwnvo96e/

OK, when you open a Command Prompt window,

cd \
dir

do you see two "Program Files" there too ?

Program Files
Program Files
Program Files (x86)

I'm thinking the second one won't be there,
when you use Command Prompt. The "dir" command doesn't
have to behave like File Explorer, and File Explorer
has a "much greater imagination".

*******

I think a previous theory that got discussed, is
there is *something* about the path of your Program Files
which has an illegal character. Like, ends in a space
or something.

"Program Files "

It's possible, if File Explorer runs into something
illegal, it displays the illegal instance first (but
nothing works in that folder), then it strips off the
illegal character and tries again. And this might be
what is giving two instances.

*******

In an *administrator* command prompt, you can make an "icacls"
listing of permissions.

cd \
cd %userprofile%
cd Downloads

icacls c:\ /save Cdrive.txt /t /c CErr.txt 2&1

notepad Cdrive.txt

I've reformatted the output in "Cdrive.txt" a bit here.
This basically just shows permissions. The long strings of zeros
are replaced by account numbers randomly generated for your install.
If you have two computers in the same room, the machines may both
have a "Steve" account, but those lists of numbers will be different
on each C: drive.

There's not really a lot of info here, so this is mainly to
see if yours is grossly different somehow. (It might take
a minute or two for icacls to list the entire partition above, so
be patient when running the command.) If you save this file
"for a rainy day", it can be used to repair the permissions
to the same state as the day you made the file. When you do
Properties on a file or folder, and use the Permissions tab,
the names in the list shown should be the same order as the
items in the icacls output.

In the actual file, these occur as pairs of lines, file name
first, permission line second. I have reformatted four lines
from the file, to make it more readable (such as it is).
SY stands for SYSTEM account. It's a shorthand notation...

Program Files
D:PAI(A;;FA;;; S-1-5-80-000000000-0000000000-0000000000-0000000000-0000000000)
(A;CIIO;GA;;;S-1-5-80-000000000-0000000000-0000000000-0000000000-0000000000)
(A;;0x1301bf;;;SY)
(A;OICIIO;GA;;;SY)
(A;;0x1301bf;;;BA)
(A;OICIIO;GA;;;BA)
(A;;0x1200a9;;;BU)
(A;OICIIO;GXGR;;;BU)
(A;OICIIO;GA;;;CO)

Program Files (x86)
D:PAI(A;;FA;;; S-1-5-80-000000000-0000000000-0000000000-0000000000-0000000000)
(A;CIIO;GA;;;S-1-5-80-000000000-0000000000-0000000000-0000000000-0000000000)
(A;;0x1301bf;;;SY)
(A;OICIIO;GA;;;SY)
(A;;0x1301bf;;;BA)
(A;OICIIO;GA;;;BA)
(A;;0x1200a9;;;BU)
(A;OICIIO;GXGR;;;BU)
(A;OICIIO;GA;;;CO)

*******

Another tools you can run in your Administrator Command Prompt,
is a third party tool "Everything.exe", which is a search tool. But
it also happens to list the entire disk for you, when it makes the
database files.

http://www.voidtools.com/downloads/

http://www.voidtools.com/Everything-1.3.4.686.x64.zip

Inside the ZIP file, is a single file "Everything.exe". This is
the portable version. It accepts command line arguments.
You can unpack the ZIP and leave Everything.exe in your
Downloads folder. Then, in the administrator command prompt...

everything.exe -create-filelist out.txt C:\

It will prepare the text file in a matter of seconds.
You can open it with "notepad out.txt" if you like.
The output for Program files, will have nice double quotes
around the pathname, so you can look for illegal characters.

"C:\Program Files",0,131297201598995371,128920152085554264,17
....
"C:\Program Files (x86)",0,131386215212441334,128920152087114204,17

In addition, you can scroll down and find the library control files.
My account has the standard set of library control files. These
files are just text files (likely XML). The first number here
is likely to be the size, the next two are created or modified
dates in nanoseconds, and I'm not sure what the last one is for.

"C:\Users\UserName\AppData\Roaming\Microsoft\Windo ws\Libraries\Documents.library-ms",6522,131273027751521844,130798962619034712,822 4
"C:\Users\UserName\AppData\Roaming\Microsoft\Windo ws\Libraries\Music.library-ms",3555,131189369343230949,130798962619970714,822 4
"C:\Users\UserName\AppData\Roaming\Microsoft\Windo ws\Libraries\Pictures.library-ms",3590,131189369343230949,130798962619814713,822 4
"C:\Users\UserName\AppData\Roaming\Microsoft\Windo ws\Libraries\Videos.library-ms",3568,131189369343230949,130798962619814713,822 4

By checking for Libraries, I just want to see if you've been creative
and made some of your own perhaps.

*******

That's not an exhaustive set of diagnostics to run. The NFI utility
wouldn't really add any value, and unlike "Everything.exe", doesn't
put double quotes around the filename for certainty.

Explorer has things like "recently used" or "quick access" items,
which it sometimes displays. But for that to get mixed in with a
regular directory display seems a bit unlikely. The recently used
items would be in their own separate group.

Paul

Nope, both there ...

SteveGG wrote:
Nope, both there ...

With exactly the same spelling ?

Maybe you'd better run NFI after all,
as each of those items needs its own filenum.

nfi.exe is inside this ZIP file.

https://web.archive.org/web/20150329...us/oem3sr2.zip

nfi C: nfi_c.txt

See if *it* has two separate entries for them.

HTH,
Paul

Paul wrote:

SteveGG wrote:

Nope, both there ...

With exactly the same spelling ?

Maybe you'd better run NFI after all,
as each of those items needs its own filenum.

nfi.exe is inside this ZIP file.

https://web.archive.org/web/20150329...us/oem3sr2.zip

nfi C: nfi_c.txt

See if *it* has two separate entries for them.

The problem you'll find with SteveGG is that he will not answer your
questions or do so in a confusing or incomplete manner. You describe
multiple solutions or instructions and he gives one blanket response to
all of them but which likely only addresses one solution you offered.
Also, your instructions won't let him [easily] see if there are
non-visible characters in the filename, like a trailing space. Here's
an example of how a trailing space got added that caused a duplicate
folder name:

https://blogs.technet.microsoft.com/...ndows-folders/

By using the "dir /x" command (i.e., adding the /x switch), the
shortnames get displayed which would eliminate any whitespace characters
(e.g., space, tab, backspace, DEL, etc). The /x switch showed them
there were 2 separate folders by different names that looked the same to
the eye. The long name for one folder had a trailing space character
which is obviously invisible to the eye in the absence of delimiters.

For me, and because I've never created a duplicate folder (well, similar
named folder that looked like another), using "dir c:\ /x" shows the
long named program folders have the following shortnames:

"Program Files" = PROGRA~1
"Program Files (x86)" = PROGRA~2

If there were a similar long-named "Program Files " (trailing space)
then it would have a different shortname, like maybe PROGRA~3.

I would think if the OP, in using Windows Explorer, had selected (moved
into) a subfolder under in one of the program folders and then clicked
in the address bar (to get rid of that stupid breadcrumb display) that
the path would show if there were spaces, like a trailing space; e.g.,
"C:\Program Files\Adobe" for the path under one program folder and the
other would show "C:\Program Files \Adobe".

Spaces are not the only hidden characters that can be used in a folder
or filename. An old trick of malware is to insert a hidden character
that the user cannot type using the keyboard or will not be handled
correctly by the input parser. One example is inserting the DEL or NUL
character in a folder or filename. You won't see those no matter what
DOS or GUI tool you use. This is also a trick used in the registry
since those characters are not available via regedit.exe for the user to
edit entries, and trying to navigate into a key to, say, change
permissions results in a parsing error because regedit just uses the
parsed value instead of the binary value. Programmatically any
character can be used in a folder name, file name, or registry key or
data item name. Only a few are reserved but that leaves lots of other
characters available to use in a value, including the non-printing
characters. As I recall, the reserved characters that cannot be
programmatically used as the value of a name (folder or file or registry
key or data item) a (less than), (greater than), : (colon), "
(double quote), / (forward slash), \ (backslash), | (vertical bar or
pipe), ? (question mark), and * (asterisk). Yep, NUL is allowed which
means "abcd" could be "ab^cd" where ^ = NUL. You won't see it so you
won't know that it is in the string unless you use a hex/binary editor
to see the string's value. I've seen NUL used but it can run afoul of
string parsers that assume strings all end in NUL as the terminating
character so the [ab]user trying to use a NUL to make it impossible for
normal users to input the string would end up shooting themself in their
own foot; that is, "ab^cd" might get interpreted as just "ab".

I haven't had to deal with non-printing characters (which includes
whitespace characters, like tab and space) for a long time. When I had
to deal with them in the file system, I had to use a disk editor that
would let me look at the folder and file records in the file system and
show me the binary value of each character in a name. I don't remember
using this one but maybe it will show the binary characters in the
string for a folder or filename in a record in the file system:

http://www.disk-editor.org/

I had to use something like that to see the non-printable characters
that some copy protection scheme used in the naming of their game files.
I also remember having to use a different registry editor that would
show me the non-printing characters (key and data names were shown as
binary strings) since regedit won't show those.

I suspect if the OP used "dir /x" that he could use a different short
name to get rid of the duplicate (not the original) folder that it would
just reappear later. Whatever created the duplicate folder would do it
again sometime later. In the article, they said the duplicate was
caused by a bad search parameter where a trailing space had been added
to the path. Since a lot of parameters for programs are stored in the
registry, I'd try searching on "\Program Files \" to see if any entries
had the trailing space character. In Search Everything, you could regex
to search the file system on "^C:\\Program Files \\" (without the double
quotes shown here). Enable regex (under Search menu) and enter the
regex string. The double backslash is needed to escape the escape
character. In regex (regular expressions), \ is used to escape the next
character so reserved characters can be used as normal characters.

Although users use regedit.exe to see the registry, it is actually a
binary database so NUL doesn't cause a problem there in the values of
names. Sometimes non-printing characters show as tall box characters
since the GUI showing the character is using it as a placeholder for a
character that it cannot display, but that doesn't always happen. Plus
space is usually shown as a whitespace character (it occupies space
versus NUL that doesn't in the display of a string).

https://support.microsoft.com/en-us/...es-for-windows

My experience with Linux users (developers mostly) is that while space
is a legitimate character is an object name that its use is frowned
upon. When Microsoft added longname support in their file system (and
the same when they moved from .ini files to the registry database), both
Microsoft and users got drunk on using the space character to make
folders and files "readable". Instead of using camel case, like
"ThisFolder\MyVacationPics" they'd use "This Folder\My Vacation Pics".
Shortnames don't permit whitespace so the OP could use those to decide
which was the duplicate folder -- but he should first determine what
created it. He might want to use SysInternals' Procmon to add a filter
on "C:\Program Files \" (with the space after Files) to see what might
be using that path. If Procmon doesn't like that filter string then use
the shortname for the duplicate/similar folder. Getting rid of the
duplicate (well, similarly named) folder won't help if it just
reappears.

Folders cannot have the same name within a parent folder. Files cannot
have the same name within the same folder. That they look the same to
your eyes does not mean they are the same. Your eyes cannot see
hitespace (the absence of a visible character) and non-printing
characters. Although I mention looking at shortnames which do not
permit whitespace, non-printing characters could still be employed.

Both have exactly the same everything. Just that the 2nd is
inaccessable.

How can I have 2 folders with the same name ?!

When I run nfi C it tells me it doesn't have access to drive C.

Same to you asshole !

I tried your "solution(s)" and they didn't work, so I said so.

Sorry if that ruffled your feathers; no I take that back.

To all responders :

This "problem" is no big deal. I just ignore that 2nd mirror duplicate
listing which is only a single line un-expanded and very easy. I can
expand and work with the 1st and the 2nd remains un-expanded.

I post on it every so often just to see if anything new etc.

I don't care for VanguardLH's snide comments, but he does provide some
useful (though not yet resolving) info.

( I don't like mysteries. )

SteveGG wrote:
This "problem" is no big deal. I just ignore that 2nd mirror duplicate
listing which is only a single line un-expanded and very easy. I can
expand and work with the 1st and the 2nd remains un-expanded.

I post on it every so often just to see if anything new etc.

I don't care for VanguardLH's snide comments, but he does provide some
useful (though not yet resolving) info.

( I don't like mysteries. )

Many lurkers and participants in this thread are interested because it
is a puzzle and because we learn from the experience of seeing a puzzle
solved.

You were admonished by VLH because there were elements in Paul's answer
which might have found/illustrated the problem's solution, but which
were not carried out.

Not all of what Paul proposed was of such difficulty that it couldn't
hae been performed by you, but the absence of a direct response to each
element -- such as 'too hard, didn't do that' -- or some other causes
the readers here to wonder what would have been found had the operation
been performed.

For example, I for one would have like to have seen a *file* result from
Paul's suggestion:

Paul wrote:
OK, when you open a Command Prompt window,

cd \
dir

do you see two "Program Files" there too ?

You said that you could see two, but they might have differed by a
trailing space (or other non-printing). You might be able to see that
trailing space by sending the dir result to a file after you change the
dir to the root with cd \

dir list.txt

Then, when you open that list.txt with something like notepad, you might
be able to use your cursor on one of the Program Files name and find a
space at dir name end.


--
Mike Easter

Many lurkers and participants in this thread are interested because it
is a puzzle and because we learn from the experience of seeing a puzzle
solved.

You were admonished by VLH because there were elements in Paul's answer
which might have found/illustrated the problem's solution, but which
were not carried out.

Not all of what Paul proposed was of such difficulty that it couldn't
hae been performed by you, but the absence of a direct response to each
element -- such as 'too hard, didn't do that' -- or some other causes
the readers here to wonder what would have been found had the operation
been performed.

I've tried everything that was proposed months ago, as I felt was
reasonable within the scope of the "problem", all to no avail as I
reported.

For example, I for one would have like to have seen a *file* result from
Paul's suggestion:

Paul wrote:
OK, when you open a Command Prompt window,

cd \
dir

do you see two "Program Files" there too ?

As I've said, yes.

You said that you could see two, but they might have differed by a
trailing space (or other non-printing). You might be able to see that
trailing space by sending the dir result to a file after you change the
dir to the root with cd \

Yes and there doesn't seem to be any difference in the 2 dirrectories
whatsoever, except as shown below. No extra spaces or other funny
stuff of any kine. Just duplicate listings of the exact same though
empty folders. The very fact that the 2nd mirror duplicate of the 1st,
automatically updates exactly according to any changes to the 1st,
suggests that it is just some phantom duplicate listing of the 1st .

Yet, bytes, files, and folders for the 1st are reasonable for what's
there, but all 3 are 0 for the 2nd (?)

dir list.txt

I'm a little fuzzy on this. Please detail.

SteveGG wrote:
dir list.txt

I'm a little fuzzy on this. Please detail.

If you first get a command prompt, then go to your main directory as
Paul described:

cd \

.... that will put you at the root of the C: drive where those
directory/folders are.

If you just input

dir

.... the directory listing will be on your screen, but if you

dir list.txt

.... then that screen display will be written to a file on that C; drive

Oops. I just checked this out in Win7 vs XP; Win7 won't let you write
to the root of C; like that. So, you have to direct the file to your
directory in Users.

dir C:\Users\username\list.txt

.... where username is your user ID to log into Windows.

Then you can open that list.txt file with such as Notepad and find each
Program Files entry. Then use your cursor to move to the end of each
Program Files line and see if there is an empty (non-printing/showing)
space there.


--
Mike Easter

SteveGG wrote:
Both have exactly the same everything. Just that the 2nd is
inaccessable.

How can I have 2 folders with the same name ?!

When I run nfi C it tells me it doesn't have access to drive C.


Must be run from Administrative Command Prompt.

In the run box, type "cmd".

When the search result comes back, the top-most item is the
Command Prompt executable. Right-click the top entry, select
"Run As Administrator", then enter

cd \
cd %userprofile%
cd Downloads

nfi C: nfi_c.txt

HTH,
Paul

Mike Easter wrote:
dir list.txt

... then that screen display will be written to a file on that C; drive

Oops. I just checked this out in Win7 vs XP; Win7 won't let you write
to the root of C; like that. So, you have to direct the file to your
directory in Users.

dir C:\Users\username\list.txt

Paul's instructions to run cmd.exe as admin will also solve the problem
of writing the dir to list.txt on C: without having to create a path to
the user's dir.

--
Mike Easter