1. This site uses cookies. By continuing to use this site, you are agreeing to our use of cookies. Learn More.

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

Discussion in 'Support' started by vefatica, Aug 3, 2011.

  1. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    "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?
     
  2. TEA-Time

    Joined:
    Jun 2, 2008
    Messages:
    282
    Likes Received:
    1
    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>
     
  3. TEA-Time

    Joined:
    Jun 2, 2008
    Messages:
    282
    Likes Received:
    1
    "\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.
     
  4. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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.
     
  5. TEA-Time

    Joined:
    Jun 2, 2008
    Messages:
    282
    Likes Received:
    1
    Ah.. I didn't realize that. Interesting.

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

    Ah...

    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.
     
  6. Steve Pitts

    Joined:
    Jul 7, 2008
    Messages:
    159
    Likes Received:
    0
    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
     
  7. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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.
     
  8. TEA-Time

    Joined:
    Jun 2, 2008
    Messages:
    282
    Likes Received:
    1
    </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.
     
  9. vefatica

    Joined:
    May 20, 2008
    Messages:
    7,959
    Likes Received:
    30
    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.
     
  10. TEA-Time

    Joined:
    Jun 2, 2008
    Messages:
    282
    Likes Received:
    1
    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.
     
  11. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    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
     
  12. DMcCunney

    Joined:
    Jun 7, 2008
    Messages:
    96
    Likes Received:
    3
    On Thu, Aug 4, 2011 at 3:27 PM, Steve Fabian <> wrote:

    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
     
  13. Rod Savard

    Joined:
    May 26, 2008
    Messages:
    481
    Likes Received:
    3
    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.
     
  14. Steve Pitts

    Joined:
    Jul 7, 2008
    Messages:
    159
    Likes Received:
    0
    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...
     
  15. TEA-Time

    Joined:
    Jun 2, 2008
    Messages:
    282
    Likes Received:
    1
    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.
     
  16. DMcCunney

    Joined:
    Jun 7, 2008
    Messages:
    96
    Likes Received:
    3
    On Sat, Aug 6, 2011 at 10:50 AM, TEA-Time <> 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.
    ______
    Dennis
     
  17. Steve Fabian

    Joined:
    May 20, 2008
    Messages:
    3,520
    Likes Received:
    4
    || 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
     
  18. DMcCunney

    Joined:
    Jun 7, 2008
    Messages:
    96
    Likes Received:
    3
    On Sat, Aug 6, 2011 at 3:28 PM, Steve Fabian <> wrote:


    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
     

Share This Page