My.Computer.FileSystem.SpecialDirectories.MyDocuments returns the wrong folder name in VB2008

Coding in VB2008 with Net Framework 3.5 in Windows 7-32 bit.

The code:

TempUserPath = My.Computer.FileSystem.SpecialDirectories.MyDocuments 

Returns the string "C:\Users\Owner\Documents" but that folder is actually named "My Documents" (i.e., is "C:\Users\Owne开发者_如何学Gor\My Documents" in the Finder).

When I try to create a new folder called "Documents" in the Owner directory, Windows asks if I want to merge its contents with the My Documents folder. If I say yes, I am left with only the My Documents folder and none named "Documents".

Thus when I attempt to read or write a file to the TempUserPath location, I get an "access denied" error. This happens even after I manually change the name of the folder from "My Documents" to "Documents".

Does anyone know why Windows seems to equate the filename "Documents" with "My Documents" within the VB environment and how I might work around this problem?

My Documents & Documents in this case are the same. Use a different folder name.

I just tried it, works fine for me.

 Dim TempUserPath As String = My.Computer.FileSystem.SpecialDirectories.MyDocuments
    IO.File.WriteAllText(IO.Path.Combine(TempUserPath, "TEST.txt"), "TEST")

You might try temporarily setting your mydocuments folder to everyone has full control to see if it's a permissions problem.

The folder My Documents that you see doesn't really exist, it's a virtual folder that has the contents of the actual documents folder. You will also see the contents of the Public Documents folder of the user Public in your own documents folder.

The name of the actual physical folder where the files are stored is correctly returned by the code. You can move the location of that folder anywhere you like, so it could just as well be D:\Birds\Pelicans instead, but you would still see it as My Documents in your home directory.

If you get an access denied error when trying to read from the folder, your program simply doesn't have the proper permissions. It doesn't have anything to do with the virtual folder name.