Return to Answer

I don't think there is a way to prevent deletion of an individual file with Unix file permissions, but I can think of a workaround: write a daemon that replaces it when it is removed. inotify-tools is perfect for this sort of thing.

There are a few ways you can replace the deleted item: copy a new one in place, or keep the real file in a safe place and just copy a link into the user's directory. For the link, you can either use a symlink or a hard link. I'd start with a symlink, but some (very few) programs don't handle symlinks correctly. If you find that the user encounters a program like this, use a hard link instead.

I don't think there is a way to prevent deletion of an individual file with Unix file permissions, but I can think of a workaround: write a daemon that replaces it when it is removed. inotify-tools is perfect for this sort of thing if you're on Linux.

There are a few ways you can replace the deleted item: copy a new one in place, or keep the real file in a safe place and just copy a link into the user's directory. For the link, you can either use a symlink or a hard link. I'd start with a symlink, but some (very few) programs don't handle symlinks correctly. If you find that the user encounters a program like this, use a hard link instead.

I don't think there is a way to prevent deletion of an individual file with Unix file permissions, but I can think of a workaround.

You can use inotify-tools to create a daemon that replaces the file if it is deleted. You could even make it so the file isn't even technically deleted - if you keep the file in a root (or some other user-owned) directory, and make a hard link to it in the users directory, when the user "deletes" the file, he will really just be removing that particular inode reference. Because there is another inode pointing to it, the file is still acutally there. The daemon can the replace the link. Or, you can use a symlink, so that when the user deletes it, he is deleting a symlink, not the actual file (and again, the daemon can replace it).

I don't think there is a way to prevent deletion of an individual file with Unix file permissions, but I can think of a workaround: write a daemon that replaces it when it is removed. inotify-tools is perfect for this sort of thing.

There are a few ways you can replace the deleted item: copy a new one in place, or keep the real file in a safe place and just copy a link into the user's directory. For the link, you can either use a symlink or a hard link. I'd start with a symlink, but some (very few) programs don't handle symlinks correctly. If you find that the user encounters a program like this, use a hard link instead.

I don't think there is a way to prevent deletion of an individual file with Unix file permissions, but I can think of a workaround.

You can use inotify-tools to create a daemon that replaces the file if it is deleted. You could even make it so the file isn't even technically deleted - if you keep the file in a root (or some other user-owned) directory, and make a hard link to it in the users directory, when the user "deletes" the file, he will really just be removing that particular inode reference. Because there is another inode pointing to it, the file is still acutally there. The daemon can the replace the link.

I don't think there is a way to prevent deletion of an individual file with Unix file permissions, but I can think of a workaround.

You can use inotify-tools to create a daemon that replaces the file if it is deleted. You could even make it so the file isn't even technically deleted - if you keep the file in a root (or some other user-owned) directory, and make a hard link to it in the users directory, when the user "deletes" the file, he will really just be removing that particular inode reference. Because there is another inode pointing to it, the file is still acutally there. The daemon can the replace the link. Or, you can use a symlink, so that when the user deletes it, he is deleting a symlink, not the actual file (and again, the daemon can replace it).