Is there a file permission that prevents deletion but allows me to write into it? I want to prevent myself from accidentally deleting the folder. Thanks

Hello,

To keep his answer short simple - no. You have three basic permissions, read, write, and execute. When you chmod a file to +w, for that user ownership, being able to write to the file/block device/directory gives you permission to pretty much do anything. Note, that if you have a directory with u+w, but you have files within the directory that are not u+w, then you will not be able to delete the directory.

Cheers,

Josh

You could alias rm so that it includes the -i option, so that it prompts you before each removal. For Bash:

This can be quite annoying, though, so you may want to check out the -I (capital 'i') option too. Obviously, this won't help if you delete things using a GUI.

Josh is right. In simple word it is not exactly possible what you are looking for. But, there is way which might help you to prevent accidental deletion of that particular folder. You can set immutable attribute on that particular folder (remember this prevents even writing to that folder until you remove the immutable attribute) and after that even root will also not be able to delete this folder unless root remove immutable attribute from that folder.

Following are the commands to set immutable attribute:

To set immutable attribute:

To remove immutable attribute:

Remember you will not be able to write anything in that folder until you remove immutable attribute. I am only suggesting this to prevent accidental deletion of the folder. That is why in the beginning I said that it is not exactly possible what you are looking for.

Hi,

like T3RM1NVT0R I would suggest 'chattr'. However, I would set the 'a' attribute instead of the 'i' attribute. This way you can still create files in that folder. The folder will be undeleteable but so will the files inside be. They also can be opened in append mode. To be able to delete files inside that folder you will have to remove the 'a' attribute recursively first.

Notice, that since newly created files will alse have the 'a' attribute you need to remove this attribute recursively. The behavior of the 'a' attribute is non-obvious in this way.

I think we should make it clear that a file's permissions control who has access to the contents of that file. But the existence and accessibility of the file itself depends on who controls the directory it's sitting in.

It may make more sense if you remember the unix philosophy of "everything is a file". A directory is basically a specialized file containing a list of all the subfiles it "contains". So if you have permission to change the contents of the directory file, then you have permission to remove any file it contains, regardless of whether or not you can access its contents.

This page has a pretty good rundown on *nix permissions:

http://content.hccfl.edu/pollock/AUn...ermissions.htm

Hard link all the files in that folder to files in another folder.
You will be able to write to any of the files and if you delete a file or the entire folder all the files will still be in the other folder.

I need to be able to prevent myself from deleting a parent folder but still be able to write/delete/move files within it. So seems like none of the solution works. Best work around is to just create a dummy file in the folder that I don't have permission to delete?

Well, if you need to delete/move the file themselves in that directory, then yes, none of the solutions will work.
How do you intend to create the dummyfile? If you simply want to give it read permission a 'rm -f' will still delete that file. Hence, 'rm -f dir/' will remove the directory. If you want to prevent the directory being deleted by 'rmdir' then it is sufficient that it is not empty.

I think I can offer two solutions that might be better:

1) Protective parent directory
Create your data directory inside a parent directory. The parent directory will act as "shield" against deletion of the datadirectory but the files
inside the datadirectory will still be re/moveable.
So instead of the directory structure
Your directorytree will look like:
The protection_dir will have the immutable flag 'i' set. This way protection_dir will not be deleteable and so will data_dir.
data_dir itself will NOT have the immutable flag enabled. Therefore the files inside data_dir will be re/moveable.
Here are the required commands:

2) Loop device
This will require that you know in advance how big the directory can actually get in order to avoid space issues. So it might not be suitable for some scenarios.
Create a loopdevice and set the 'a' attribute for this loopdevice. When you mount it you will be able to create and delete the files
inside but the loopdevice itself will not be deleteable.
Procedure, e.g. 1G loopdevice:
Now create the mount directory for loopdrive and set the 'i' flag on the mount directory. This way you can also ensure
that the mount directory will not be removed accidentally.
Finally, mount it:
A funny thing to notice is that you will get an error (at least I do) when you try mount it like 'mount -o loop loopdrive data_dir'.
However, if the file loopdrive does have the 'i' flag set instead of the 'a' flag then the latter mount method does work. Strange.

There is one major drawback with the loopdrive solution. Every time you want to setup the loopdevice with
losetup /dev/loop0 loopdrive

you will have to remove the 'a' flag first and add it again afterward.

PS:
I used loop0 in my example. You might have to use loop1 or higher if loop0 is already taken. Issue 'losetup -f' to display the next free
loopdevice.

1 members found this post helpful.