I notice that a folder called “My Documents” shows up in two places in Windows, and there’s another that seems to have the same
things in it as well. Are all these copies taking up extra space on my hard drive? Which one should I use? Can I get rid of any of
them?
They’re not copies.
In an effort to be helpful (which we’ve heard before), Windows actually treats your My Documents folder differently … it’s
“special”.
Which one is real? What are the implications? Let’s look at that.
]]>
First, let’s be clear about the issue. Here’s a Windows Explorer where I’ve highlighted some specific branches in the displayed folder tree:

As you can see, “My Documents”, or its contents, are shown in no less than 3 places in Windows Explorer.
Rest assured there’s only one copy of the contents of “My Documents”.
Two of the three locations shown in Windows Explorer are “aliases” or “links” to the real “My Documents”. In fact, you can consider all three pointers to the contents:
Which one is “the real one”? In a sense, all of them are, and it really doesn’t matter; they’re all equal. In another sense,
they’re not really equal, and most people consider the one found in the hard disk path “C:\Documents and Settings\
So why have all those other locations?
At least one clue can be found in Windows Vista, where that “official” one was moved to “C:\Users\
Here’s the basic difference:
-
References like “C:\Documents and Settings\
\My Documents” are location specific. When you or a program uses that kind of a reference to “My Documents”, it’s saying “I know exactly where this is and who it belongs to; it’s on the C: drive in this folder”. That’s actually a pretty traditional way to access files. Since this is the most complete identification of the data’s actual location on the hard disk, it’s typically what we consider the official or canonical location. -
References via the link on your Desktop, on the other hand, are location and user independent. That’s more like “I don’t know or care where it is on the hard drive, just use the “My Documents” for the currently logged in user.”
That last one is pretty flexible, since of course, you can move the “My Documents” folder to another drive if you like. If you do that then the “C:\Documents and Settings” approach will no longer work, but the updated shortcut will.
Finally, we have this “LeoN’s Documents” in the example above.
As I kind of alluded to earlier, each user account gets its own “My Documents” folder. Specifying the full “C:” based path name assumes you have the name of the user who’s data you want to access, whereas the shortcut automatically points at that of the currently logged in user.
The “LeoN’s Documents” is a combination of abstracting out the “I don’t care where it lives” of a shortcut, while keeping the “I know who’s documents I want to access” of the full path. With proper security settings, it allows multiple users on the same machine to share documents. (To be honest, I’ve rarely, if ever, actually seen this used.)
Bottom line: do nothing. Multiple “My Documents” are an expected, if somewhat confusing, layout. It doesn’t imply any of the contents are somehow being duplicated or taking up unwarranted disk space.


Can you delete the My documents folder on the C drive if you have moved it to another drive?
How can you make each My Documents unavailable to others, without having it on the C drive?
I had 24 Perl scripts that referred to ‘$ENV{USERPROFILE}\\My Documents’ (that would be ‘%USERPROFILE%\My Documents’ in a .bat file). After I updated to W11, that path no longer exists. I had to change each occurrence to ‘$ENV{USERPROFILE}\\Documents’.
That was in Perl, but I suspect it would be a problem in any script (Python, Bash, etc.) that refers to ‘My Documents’. It might also be a problem if ‘My Documents’ appears in the PATH variable. I did not test that.
Leo, you might want to point out this ‘gotcha’ in one of your treatises on W10 to W11 upgrades. It’s going to affect only a few of your more sophisticated readers, but they’ll be grateful for the tidbit.
Correction: The ‘My Documents’ path does exist, but it doesn’t point to ‘Documents’ any more. In each case, I was actually pointing to $ENV{USERPROFILE}\\My Documents\\[some subdirectory], and that is the path that no longer exists.