Welcome!

By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!

OT:Explain Win7's "start menu" folder?

May
12,834
163
"users\user\start menu" ... what is it? TCC says it's a junction with attributes _HS_D___L___I_ (a link to "...\appdata\...\start menu"). TCC can enter it with CD but it appears empty to TCC. In Explorer it looks like a shortcut but trying to open it results in "Access denied" even though properties\security says I have full control.

Why does it act so strangely? Why can't I enter it with explorer? Why can I enter it with TCC? Why does it appear empty to TCC?
 
"users\user\start menu" ... what is it? TCC says it's a junction with attributes _HS_D___L___I_ (a link to "...\appdata\...\start menu"). TCC can enter it with CD but it appears empty to TCC. In Explorer it looks like a shortcut but trying to open it results in "Access denied" even though properties\security says I have full control.

Why does it act so strangely? Why can't I enter it with explorer? Why can I enter it with TCC? Why does it appear empty to TCC?

The answer here explains what they are:

http://answers.microsoft.com/en-us/...settings/915eecc8-6a07-4d6a-8ca5-468ee51e9484

Dunno why TCC (and CMD) can CD into it (and the many other junctions), though.

I COPY CONed a file into my "C:\Users\user\Start Menu" and it actually landed in "C:\Users\<user>user\AppData\Roaming\Microsoft\Windows\Start Menu", so it looks like it works. Heh

Hmm.. I guess being able to CD into junction is necessary to be able to make use of them..?
</user>
 
"\Documents and Settings" is another junction.

DIR "\Documents and Settings\user(that exists in \Users)" shows the contents of "\Users\user".

Likewise, DIR "\Documents and Settings\user\Start Menu\programs" shows the contents of "\Users\user\AppData\Roaming\Microsoft\Windows\Start Menu". Of course, DIR "Users\user\Start Menu\programs" points to the same place.
 
On Thu, 04 Aug 2011 01:08:11 -0400, TEA-Time <> wrote:

|"\Documents and Settings" is another junction.
|
|DIR "\Documents and Settings\user(that exists in \Users)" shows the contents of "\Users\user".
|
|Likewise, DIR "\Documents and Settings\user\Start Menu\programs" shows the contents of "\Users\user\AppData\Roaming\Microsoft\Windows\Start Menu". Of course, DIR "Users\user\Start Menu\programs" points to the same place.

Yeah. But why do they limit access to these places whan the user can get to
their destinations anyway (if he works hard enough).

While the owner (me), SYSTEM, and Admins (me) all have full control over these
things, "Everyone" has "list denied" and that specific denial seems to take
precedence (I removed it and now I (Explorer, TCC) can use "...\Profile\Start
Menu". How could anyone, including SYSTEM, use them with that denial in place?

I still why they're made inaccessible. The user can get to their destinations
anyway, often more easily via the links.
 
Yeah. But why do they limit access to these places whan the user can get to their destinations anyway (if he works hard enough).

While the owner (me), SYSTEM, and Admins (me) all have full control over these things, "Everyone" has "list denied"

Ah.. I didn't realize that. Interesting.

and that specific denial seems to take precedence

Yeah, Deny permissions have precedence over Allows. I do know that.

(I removed it and now I (Explorer, TCC) can use "...\Profile\Start Menu".

Ah...

How could anyone, including SYSTEM, use them with that denial in place?

I still why they're made inaccessible. The user can get to their destinations
anyway, often more easily via the links.

I'm guessing to discourage them from being widely used since they only exist for backward compatibility with older programs, and will probably be dropped sooner than later. You can go "through" them with "\Documents and Settings\user\Desktop", but getting the access denied when trying to browse down through them forces you go about it using the new correct path.
 
I still why they're made inaccessible
The usual MS 'nanny knows best' approach. They are provided for backwards compatability only, so (for instance) a program that requests a file from

C:\Documents and Settings\All Users\Documents\My Music\

actually gets that file from

C:\Users\Public\Music

(or in my case D:\Users\Public\Music). Presumably this works provided that the end file or directory is accessible even though some or all of the intermediate points are these 'deny all' junctions.

However, MS apparently don't want users continuing to use those locations directly (for reasons we can only speculate on) and thus breaks them for that route. If that bugs you as much as it bugged me, you may find the following a useful starting point for a fix (I chose to delete and recreate them rather than messing with their ACLs). Bear in mind, however, that this routine as it stands also remaps links to C:\Users to D:\Users and also contains an IF in the GLOBAL that is almost certainly unnecessary for anyone else :)

Code:
@ECHO OFF
REM Routine to identify damaged JUNCTIONs or symbolic links and reinstate them
REM in such a way that they work properly from both Explorer and the command line
SETLOCAL
PUSHD %1
REM This GLOBAL recurses over every directory below the current one (eg. C:\)
REM and the FOR then finds all junctions within that directory
global /h /n /i /q if %@LEFT[33,%_cwd] != C:\really_not_the_old_user_folder (for /a:j %dir in (*) gosub check_junction)
POPD
QUIT 0


:check_junction
echo %@right[4,   %@files["%dir",d]] %@full["%dir"] = %@truename["%dir"]
REM We only have anything to do if we cannot see any directories within
REM the given directory (there should always be two - . and ..)
IFF %@files["%dir",d] == 0 THEN
  ECHO Duff: %@ATTRIB["%dir"] %@full["%dir"]
  SET dir_attr=%@ATTRIB["%dir"]
  SET target_dir=%@truename["%dir"]
  *RD "%dir"
REM Need to decide whether this should be a junction or a symbolic link
REM If this points to the Users structure then it needs changing to D
  IFF "%@LOWER[%@LEFT[8,%target_dir]]" == "c:\users" THEN
    SET target_dir=%@SUBST[0,D,%target_dir]
  ENDIFF
  *MKLINK /J "%dir" "%target_dir"
  *ATTRIB /D +%@STRIP[_JLNDECP,%dir_attr] "%dir"
ELSE
  ECHO  OK : %@ATTRIB["%dir"] %@full["%dir"]
ENDIFF
RETURN
 
Here's a more perplexing one. According to TCC,

Code:
z:\users\vefatica> dir /a my*
 Directory of  Z:\Users\vefatica\my*

2011-07-30  16:23    <JUNCTION>    My Documents
[Z:\Users\vefatica\Documents]

But if I go to z:\Users\vefatica with Explorer, I do not see "Documents".
Rather, I see two things named "My Documents". One has the shortcut-like arrow
on its icon. If I TCCHere (my own shell extension) to the one without the
arrow, TCC says _CWD is "z:\users\vefatica\documents" (no "My") and TCC can list
the contents. If I enter the one with the arrow (which I can't do in Explorer)
the same way, TCC says _CWD is "z:\users\vefatica\my documents" and TCC sees
nothing inside (but can enter (CD) and then list (DIR) the directories (like
"fax") that are actually there.

So how (and why) does Windows manage to show me two things in the same folder
with the same name?

Another oddity ... though I cannot see "Documents" when in Explorer, I can, from
the "Run" dialog

Code:
explorer z:\users\vefatica\documents

An explorer window opens. It has "z:\users\vefatica\documents" in its caption
and shows "ZZ - Windows7 (Z:) - Users - vefatica - My Documents" in its location
bar.
 
Here's a more perplexing one. According to TCC,

Code:
z:\users\vefatica> dir /a my*
 Directory of  Z:\Users\vefatica\my*

2011-07-30  16:23    <junction>    My Documents
[Z:\Users\vefatica\Documents]
But if I go to z:\Users\vefatica with Explorer, I do not see "Documents". Rather, I see two things named "My Documents". One has the shortcut-like arrow on its icon. If I TCCHere (my own shell extension) to the one without the arrow, TCC says _CWD is "z:\users\vefatica\documents" (no "My") and TCC can list the contents. If I enter the one with the arrow (which I can't do in Explorer) the same way, TCC says _CWD is "z:\users\vefatica\my documents" and TCC sees nothing inside (but can enter (CD) and then list (DIR) the directories (like "fax") that are actually there.

So how (and why) does Windows manage to show me two things in the same folder with the same name?

Another oddity ... though I cannot see "Documents" when in Explorer, I can, from the "Run" dialog

Code:
explorer z:\users\vefatica\documents
An explorer window opens. It has "z:\users\vefatica\documents" in its caption and shows "ZZ - Windows7 (Z:) - Users - vefatica - My Documents" in its location bar.

</junction>The Run dialog is seeing through the "trickery" going on with Explorer.

I'll explain. :-)

It's because of the desktop.ini that's in the (real) Desktop folder and the LocalizedResourceName entry in it, which is an index to the string "My Documents" in shell32.dll.

desktop.ini files are in MANY places to change what Explorer actually shows the user. Just a few others are the Recycle Bin, Temporary Internet Files, and Fonts. Another entry in some desktop.ini files is CLSID, which makes Explorer load a DLL that makes Explorer show buttons and links related to the content. The desktop.ini in the Fonts folder is an example of that.

Of course, desktop.ini files are nothing new. They've been around since Win95.
 
On Thu, 04 Aug 2011 13:30:42 -0400, TEA-Time <> wrote:

|It's because of the desktop.ini that's in the (real) Desktop folder and the LocalizedResourceName entry in it, which is an index to the string "My Documents" in shell32.dll.
|
|desktop.ini files are in MANY places to change what Explorer actually shows the user. Just a few others are the Recycle Bin, Temporary Internet Files, and Fonts. Another entry in some desktop.ini files is CLSID, which makes Explorer load a DLL that makes Explorer show the user buttons and links related to the content. The desktop.ini in the Fonts folder is an example of that.
|
|Of course, desktop.ini files are nothing new. They've been around since Win95.

Thanks. I never knew exactly what they did. Over the years I have deleted them
willy-nilly (without undesirable consequences) because I don't want to see them.
 
Thanks. I never knew exactly what they did. Over the years I have deleted them willy-nilly (without undesirable consequences) because I don't want to see them.

You're welcome!


For a little more insight, take a look at the following key and the structure below it in the registry:

HKEY_LOCAL_MACHINE\SOFTWARE\Classes\CLSID\{BD84B380-8CA2-1069-AB1D-08000948F534}

{BD84B380-8CA2-1069-AB1D-08000948F534} is the CLSID from the desktop.ini in the Fonts folder. You can see it loads fontext.dll, and pulls a string and an icon from fontext.dll and a couple more strings from shell32.dll.
 
From: vefatica
| Thanks. I never knew exactly what they did. Over the years I have
| deleted them willy-nilly (without undesirable consequences) because I don't want
| to see them.
Likewise!
--
Steve
 
On Thu, Aug 4, 2011 at 3:27 PM, Steve Fabian <> wrote:

> From: vefatica
> | Thanks. I never knew exactly what they did. Over the years I have
> | deleted them willy-nilly (without undesirable consequences) because I don't want
> | to see them.
> Likewise!

Maybe this is a difference between the mindsets of a programmer and a
systems administrator. I can't imagine deleting something
willy-nilly, *without knowing what it is and what it does*, precisely
*because* of possible undesirable consequences. (For the SysAdmin, it
tends to be a case of "You shoot yourself in someone *else's* foot.")


______
Dennis
 
I'm guessing to discourage them from being widely used since they only exist for backward compatibility with older programs, and will probably be dropped sooner than later. You can go "through" them with "\Documents and Settings\user\Desktop", but getting the access denied when trying to browse down through them forces you go about it using the new correct path.

I'm sure that's it... they don't want users actually using those locations. It could cause confusion; some people would think they have duplicate files on their system.

The junctions are only there to support programs whose brain-dead programmers decided to use hardcoded paths instead of using the proper API to get the right path. When those programs are writing to those areas, they don't need to "list" the files so the DENY ACL doesn't affect them.

And yes, DENY ACLs absolutely take precedent over ALLOW ACLs.
 
It's because of the desktop.ini that's in the (real) Desktop folder and the LocalizedResourceName entry in it, which is an index to the string "My Documents" in shell32.dll
FWIW I've not had any trouble from simply deleting that line in various desktop.ini files so that Windows Explorer et al stop lying to me about what the folder is called. Of course, this may have deleterious effects if English is not your first language and you'd like to see a native language representation of the folder names...
 
Maybe this is a difference between the mindsets of a programmer and a systems administrator. I can't imagine deleting something willy-nilly, *without knowing what it is and what it does*, precisely
*because* of possible undesirable consequences. (For the SysAdmin, it
tends to be a case of "You shoot yourself in someone *else's* foot.")

FWIW I've not had any trouble from simply deleting that line in various desktop.ini files so that Windows Explorer et al stop lying to me about what the folder is called. Of course, this may have deleterious effects if English is not your first language and you'd like to see a native language representation of the folder names...

I don't think desktop.ini files have anything to do with the way Windows or programs operate. They're only there to affect what the user sees. I've never seen a case where the modification or absence of a desktop.ini file actually breaks Windows or a program. The user just doesn't see what M$, in their infinite wisdom, had in mind.
 
On Sat, Aug 6, 2011 at 10:50 AM, TEA-Time <> wrote:

> ---Quote (Originally by DMcCunney)---
> Maybe this is a difference between the mindsets of a programmer and a systems administrator. *I can't imagine deleting something willy-nilly, *without knowing what it is and what it does*, precisely *because* of possible undesirable consequences. *(For the SysAdmin, it tends to be a case of "You shoot yourself in someone *else's* foot.")
> ---End Quote---
>
> ---Quote (Originally by Steve Pitts)---
> FWIW I've not had any trouble from simply deleting that line in various desktop.ini files so that Windows Explorer et al stop lying to me about what the folder is called. Of course, this may have deleterious effects if English is not your first language and you'd like to see a native language representation of the folder names...
> ---End Quote---
> I don't think desktop.ini files have anything to do with the way Windows or programs operate. * They're only there to affect what the user sees. * I've never seen a case where the modification or absence of a desktop.ini file actually breaks Windows or a program. *The user just doesn't see what M$, in their infinite wisdom, had in mind.

A desktop.ini file controls the appearance of whatever folder the ini
file is in, so you see things like icons or a detailed list. You
won't shoot Windows or your programs in the foot by deleting them.

It was deleting them *without* knowing what they were or did that
prompted my comment.
______
Dennis
 
|| I don't think desktop.ini files have anything to do with the way
|| Windows or programs operate. * They're only there to affect what the
|| user sees. * I've never seen a case where the modification or
|| absence of a desktop.ini file actually breaks Windows or a program.
|| *The user just doesn't see what M$, in their infinite wisdom, had in
|| mind.

Just depersonalizing the PERSONAL COMPUTER.

|
| A desktop.ini file controls the appearance of whatever folder the ini
| file is in, so you see things like icons or a detailed list. You
| won't shoot Windows or your programs in the foot by deleting them.
|
| It was deleting them *without* knowing what they were or did that
| prompted my comment.

Files with no meaningful content which suddenly appear in previously empty directories just because Windows Explorer had an opportunity to look at the directories are the ones I (and Vince) deleted to avoid directory pollution.
--
Steve
 
On Sat, Aug 6, 2011 at 3:28 PM, Steve Fabian <> wrote:


> | A desktop.ini file controls the appearance of whatever folder the ini
> | file is in, so you see things like icons or a detailed list. You
> | won't shoot Windows or your programs in the foot by deleting them.
> |
> | It was deleting them *without* knowing what they were or did that
> | prompted my comment.
>
> Files with no meaningful content which suddenly appear in previously empty directories just because Windows Explorer had an opportunity to look at the directories are the ones I (and Vince) deleted to avoid directory pollution.

I don't believe he knew that when he deleted them. He just didn't
know what they were, so away they went. I've spent the odd hour
trying to clean up the mess and put things right when users I
supported did that, so I take a dim view of the notion.


______
Dennis
 

Similar threads

Back
Top