New
#21
You didn't follow the directions. I specified to rename the folder shortcut Sond To SendTo
that is how it will appear in the SendTo Menu.
I've done this on the last 4 or 5 Windows OS and it works every time.
You didn't follow the directions. I specified to rename the folder shortcut Sond To SendTo
that is how it will appear in the SendTo Menu.
I've done this on the last 4 or 5 Windows OS and it works every time.
Ok, I am getting a better idea what you are saying. I don't think I've run into this one before. When you do shell:sendto it does open the correct folder? How old is your user account? I'm wondering if this is one of those cases where the user account is corrupt.
Unfortunately in Windows,if that is the case, it is usually faster to create a new account than to fix the old one. As an experiment it may be a good idea to create a new user account and put some stuff in the SendTo. See if it is normal or has the defaults same as this one?
Windows has to be sourcing your context menu Send to list from somewhere. That somewhere, of yours, may be set to an incorrect location.
To prove or falsify my claim, Tecknomage, could you delete the Documents file that resides in your C:\Users\Edward\AppData\Roaming\Microsoft\Windows\SendTo folder. After doing so, does your Send to list, in your context menu, reflect the change? I.e. Does "Documents" show up as an item in your Send to afterwards?
If not then, evidently, Windows isn't looking in your C:\Users\Edward\AppData\Roaming\Microsoft\Windows\SendTo folder to create your Send to list, and may be an indication of a loose registry value.
Notice that "TeamViewer" is missing from the Send to context menu:
I then deleted "Documents" from this folder
C:\Users\username\AppData\Roaming\Microsoft\Windows\SendTo
The Send to context menu did change - as expected - i.e. "Documents" is no longer shown in the Send to context menu. That probably means that the context menu is being built from the folder that I think that it is coming from and yet "TeamViewer" is still missing from the Send to context menu (because of NTFS permissions).
Maybe Tecknomage should check to see that the Send to folder is set to inherit and propagate the correct NTFS permissions.
Ah, of course, let's not forget about NTFS permissions. It's possibly incorrectly set permissions that is the problem the OP experiences rather than a busted registry key.
Tecknomage, you should run and post the output from Icacls here for one of the files that exist in your SendTo folder, but do not appear in your Send to context menu.
Last edited by Pyprohly; 02 Jul 2015 at 09:41.
Apologies. Icacls is a Command Prompt command that deals with viewing and setting NTFS permissions (never mind what those are).
For one of the items in your SendTo folder, Tecknomage, that does not appear in your context menu Send to, would you be able to open up a command prompt and enter in a command similar to
and take a screenshot or copy paste the command's output here so that we can determine if the permission settings on that file is correctly set.Code:icacls "C:\Users\Edward\AppData\Roaming\Microsoft\Windows\SendTo\EditPad Pro.lnk"
Here's what I got:
Microsoft Windows [Version 6.1.7601]
Copyright (c) 2009 Microsoft Corporation. All rights reserved.
C:\Users\Edward>icacls "C:\Users\Edward\AppData\Roaming\Microsoft\Windows\SendTo
\EditPad Pro.lnk"
C:\Users\Edward\AppData\Roaming\Microsoft\Windows\SendTo\EditPad Pro.lnk NT AUTH
ORITY\SYSTEM(I)(F)
BUILTIN
\Administrators(I)(F)
Edward-
PC\Edward(I)(F)
Successfully processed 1 files; Failed processing 0 files
C:\Users\Edward>
C:\Users\Edward>
C:\Users\Edward>