Windows file systems have a "read-only" flag. That is simpler than having to set DACL permissions for such a simple effect.
In a command prompt, use the ATTR command. In the GUI shell it should be in the Properties, though the gui might do something complex and beyond what you really wanted.
Also, if you re-create a directory with the same name you can then apply "restore previous versions" on it.
Update
I experimented on a Win7 system. The GUI delete (without recycle bin) ignores the R
flag on the directory. There are no additional prompts warning about it, either, like I've seen for H
and/or S
flags. Issuing rd
from the command line gives access denied as expected. However, you can't just rd
a non-empty directory anyway: delete file and remove directory are different commands. A command to recursively remove a directory with contents will remove the contents and than fail to remove the now-empty directory.
So protecting the directory itself doesn't work in the GUI action you have in mind. And it implies that any fancier approach to preventing the directory itself from being removed won't prevent it from being emptied first! You said you still want normal access within the directory to create and remove files, so locking it down completely is not a solution for you.
The best solution seems to be the symbolic link. Making a symbolic link (new style, what Windows Vista and above now call a symbolic link) to the directory on the desktop, when the directory actually exists somewhere else, works in the sense that if I delete the desktop icon (shift-delete, no recycle bin) the actual directory is unaffected as only the link was deleted.
Shift-Delete of the desktop icon did not care if it was marked with the R
attribute.
A program using the standard Windows file-open dialog box navigated through the symlink with no problems. It actually resolved the name of the linked directory, so the file opened was the real name; e.g. Desktop\MyFolder
became D:\scratch\MyFolder
as I navigated through it.
Using an old-style link (a Junction), the program saw the name with the junction still in the path; e.g. C:\Users\john\Desktop\MyFolder\test.txt
so the fact that it's a link is invisible. Yet, the GUI delete action still treated it as a link, not invisibly following it.
Either way, if a program does use the aliased name directly it will work. But having files sometimes seen with one name and sometimes the other could confuse things.
Conclusion
Use a Junction on the desktop with the folder really located elsewhere, and it will be completely transparent that this is what is happening. Optionally, using DACL to prevent accidental deleting of the junction point file on the desktop. At least, have a script to re-create it when needed.
Bonus
I've not tried this, but I wonder if you could have something in "new items" to re-create the junction or symbolic link? Then just right-click on the now-empty desktop, choose New... and pick "Desktop Junk" from the menu. Have it restore everything you really did want on the desktop.
69The desktop is the worst place to store critical data, store it somewhere else and make a shortcut to it on the desktop. – Moab – 9 years ago
If I now move that folder to somewhere and create a shortcut with the same name on Desktop, will everything depending on the folder continue to work normally? – codezombie – 9 years ago
2Its common practice, a shortcut just leads to the folder, everything will work. – Moab – 9 years ago
3@JasonStack probably, but not necessarily. If you move the folder, and you have some other program or document that assumes the folder is on your desktop, it might break something. It could happen if you have files that link to other files, for example. If that doesn't apply to your content, then you probably won't have any issues. – barbecue – 9 years ago
I have installation files for a program stored in this folder. So, should replacing it with a shortcut break the working @barbecue? – codezombie – 9 years ago
http://superuser.com/questions/720486/how-to-prevent-users-from-deleting-a-folder-while-still-giving-them-modify-perm – BlueBerry - Vignesh4303 – 9 years ago
8Don't do that.
<hr/> Make backups. **Always make backups**. On external media. **Always make backups on external media.** Also, you should check out Windows' File History/Previous Versions feature. It's pretty handy. – forloop – 9 years ago
1“If I now move that folder to somewhere and create a shortcut with the same name on Desktop, will everything depending on the folder continue to work normally?” @JasonStack I answered that in my updated Answer, below. I'd like to point out that Junctions were introduced for the express reason to be able to move things to a different physical volume without affecting anything. – JDługosz – 9 years ago
There is one thing you can do... create a deep nest of folders within that directory on the desktop and place a file or two in each level. Bonus points if the file you create has a long name too.
– Reece – 9 years agoIf you have long enough folder names and a deep enough path, you won't be able to delete the folder by accident because the recycle bin will throw an error message about the file name(s) being too long for the destination. You would need to delete contents from the deepest level backward (http://superuser.com/questions/755298/how-to-delete-a-file-with-a-path-too-long-to-be-deleted).
This is a crazy suggestion but it is so crazy it might just work: Find a guy who can write a little code (or a full fledged programmer), ask him to create a simple application that keeps a handle to at least one of the files in the folder. No other software will be able to delete the file without getting you to close the application that has the handle's (except for a driver and NT). I am a programmer and used to do it when I had to share my computer. – nom – 9 years ago
1I really hate when people store data on their desktop. Data should be stored at directories likes Documents. The desktop is meant for your current project data, and temporary storing of files. – KaareZ – 9 years ago
You know @KaareZ Desktop is very convenient to access. – codezombie – 9 years ago