Shell Programming and Scripting

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..

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)