I looked into the sticky bit, but I think, if possible, that I would prefer to have the file recreate itself after deletion. The file is several directories deep, and from time to time the top level directory will be trashed. I need the file to recreate after this. Is it possible to perhaps create a symlink that, if the file is deleted, the source file will recreate it?
---------- Post updated at 03:33 PM ---------- Previous update was at 02:56 PM ----------
Any ideas are welcome!
Do you want the file contents re-created or just a the file? If just the file, have a script that checks to see if the target file exists and if not, touch $file. If you want the contents as well, have a similar script that checks for existence and if it isn't there, copy a new one in place. From what you say you'll probably have to create the directory structure as well. Have a look at mkdir -p for that.
peterro, Thanks for answering.. I was wondering if there was something simpler.. Like a way to actually have a symlink that, if the target file was deleted, that the source file would recreate it.
Can you give more details? What is trashing your directory structure? Is this just a blank file, or a log file that you will be writing to when needed? I don't understand why you'd want to keep recreating a dir structure and a file. Without knowing more I'd tend to agree with peterro's comments.
There's no fundamental-to-the-system way to make a file that ressurects itself. If you want to leave a file alone, the natural thing to do is to stop trashing it! 
And change file and directory permissions to prevent people from trashing it in the first place. I'm reminded of a story:
try using hard links.
ie:
ln /myfs/protected/directory/master.file /myfs/dir/that/might/be/trashed/your.copy.file
if your.copy.file gets removed, you can just create another link. keep master.file in a safe place and you will always have at least one file there. the files must exist on the same file system though. the file will only be unlinked if all references are removed.
I am using a link. This file is a userChrome.css file within a user's firefox profile that is configured to disable/remove the network settings button so that users arent changing their proxy settings. The problem is sometimes the users' firefox profile gets corrupted and we trash it. When firefox starts up after that, it creates a new profile, minus the userChrome.css file which is custom. I was hoping I could use a linked userchrome file in their profile, and if it was deleted, to have it somehow regenerate from the destination linked file. basically a link that when broken, fixes itself.
Ah.. I think you misunderstand what is meant by "creating a link". What you should do is create a backup directory path someplace safe. Then in that directory, create a HARD link to the user's userChrome.css file. When the new profile is created, simply create a HARD link in the user profile to the backup path.
This is what Frank is saying.. Not a soft link (aka symbolic link).
Quick note: The filesystem only really know files by their inode. The entry in the directory structure actually contains a filename and inode number in the filesystem. (The OS uses a vnode constructed from an inode.) Each inode contain a reference count. As long as the reference count is > 0, the file data will exist. So if you create a hard link to a file (using an existing filesystem directory entry or inode with a non-zero reference count), you create entry (path) in the filesystem that is just as valid as any other filesystem path that points to that inode. The file (from an system perspective) will not be deleted until the last hard link to the inode is deleted. Deleted it from one path and it's not there. But it is if you use one of the other hard links.
If the data is trashed, you can't restore it unless you are willing to pay the back-up-a-copy-at-creation-time cost and associated restore-it-fast-automatically costs..
Note that symbolic links (aka soft links) create a directory entry that contain the path to another directory entry. It doesn't point to an inode. So, this won't help you keep the file from disappearing.
Neither of these measures will prevent the chrome file from being corrupted. It's nearly the same problem as my example, for which they were forced to create a daemon to keep restoring a file which got corrupted or deleted.
I'd be tempted to just script it in their xinitrc or whatever equivalent you have. Every time they login, destroy their profile and restore it from a tarball somewhere.
In the original post, the problem description stated that a high level directory get's trashed and the chrome file is several levels lower. Hence, this should be an effective and low impact bandage for the symptoms. No extra staff or system resources (i.e. daemons, cpus, memory, etc) other than a few bytes in the backup directory.
The preferred solution would be to eliminate the source of the corruption of the higher level directory. But it may not be the best mission critical solution for the moment.
I would still love to hear a solution, but what I came up with was a login script that checked if the file exists and if not it would create it. I guess a self fixing link is a non-existent entity in the UNIX world.
Naive.
Sometime you just have to bit your tongue, shake your head and walk away.. :rolleyes:
And sometimes not .... 
"jp4245a" is 100% correct: "eliminate the source of the corruption of the higher level directory".
There are only so many "Band Aids" you can stick to a computer before it bleeds to death.
(Methyl Sep 2009)