At risk of twisting the rules to nearly the point of breaking (if you think this goes too far mods, I apologise and accept that this should be deleted), I'm hoping someone might be able to cast a little light on the following problem regarding hard links to files.
I don't think that you're breaking the rules with a 2 week bump. Hard links are only possible within a file system. You can't can't make a hard link from one file system into another file system. /proc is a separate file system and you can't create links there at all. An extra link in /proc won't help you anyway. Forget /proc. It goes nowhere.
The only tool with a shot at this is fsdb, but I don't know fsdb well enough to tell you the precise steps. Call this plan A. The general steps I would try are:
1 create some file
2 create an extra link to the file with very bizarre name (more easily found and easy to sure you have the right one)
3 hit the power switch to drop power to the box
4 come up in single user mode and run fsdb
5 edit the directory entry to point to my file
6 edit the inodes to increment and decrement the usuage counts
7 run fsck
And I would practice on a test system before I tried it for real.
If I couldn't get it to work, plan B:
1 drop power
2 ship the disk to a data recovery specialist with experts who can implement plan A.
Yoicks! Probably a little bit extreme for what I need (as I can recover the data from the proc filesystem's filehandle list). Good point about the cross-filesystem thing, that explains why ln isn't going to play ball.
What I guess I'm really looking for is a way to take an inode number (something that still has at least one link to it) and create a 'file' (aka directory entry) on the same filesystem that links to it.
fsdb sounds like something to take a look at, but it also sounds like a great way for me to really fubar a filesystem. Methinks I'll play with it on a lab server 
As an aside, some kernels - BSD is one - have an fhopen call that will open a file based on inode number.
I don't see how that helps since you can read the file via /proc/<pid>/fd. If the filesystem still has the data out there somewhere, can you read the file onto media to rescue it?
I stumbled onto this thread while experiencing a similar problem. A file had been deleted while a process still had it opened.
Use lsof to determine the inode number of the file
install icat (Google icat-sleuthtools)... for ubuntu it's apt-get install sleuthtools
then use icat to copy the file to the new location:
icat -hf ext /dev/xxx <inode> > /path/to/copy.file
-h tells it to skip over any holes in the file (sparse data)
-f ext tells it to use ext2/3
/dev/xxx is the device (NOT THE MOUNTED DIRECTORY!!!)
<inode> is the node returned from lsof
Hope this helps!
-Ecifer
That's rather cool, will bookmark 
In my case it very similar to the abilities granted via the /proc/<pid>/fd/<filehandle> but being able to refer to inode number directly is a trick I'll be pleased to have in my toolbox! 
For the record... that only worked on 2 out of 3 attempts for me... it really depends on whether or not the open process is actively using the file at the time.