How do I re-attach an i-node

[Tim D Fulford]

Hi

I've got a process where someone had done rm whilst the process was still attached. Unfortunately I'm not able to stop this process (it will constitute an outage) and the FS is [obviously] still full.

I know the i-node number (4122 fyi). I want to re-attach it to a dummy file[handle?] so I can echo /dev/null to it. How can I re-attch the i-node?

Tim

[Patrick Wallek]

Have a look at this article from Sys Admin magazine.
http://www.samag.com/print/documentID=16685

I'm not sure this will work for you, but it's the closest thing I can think of for what you require.

[A. Clay Stephenson]

Hi Tim:

The tool you are looking for is called 'fsdb'. However, you really don't want to use this guy as it is extrememly dangerous. Man fsdb_vxfs (or fsdb_hfs) for details. I'm not going to give you the specifics because you really don't want to do this especially on a mounted, active filesystem. I rather doubt that trying to copy to /dev/null is going to help anyway because the file is probably opened in append mode and will continue to try to write at EOF.

[harry d brown jr]

The Coroners Toolkit (TCT) has an "unrm", but it's only good for HFS filesystems. But, I'm wondering if you could modify it, especially if you have the inode? Any thoughts anyone?

live free or die
harry

[Tim D Fulford]

Patric:
Thanks for the pointer to the sysadm site. unfortunately the documentID=16685 does not seem to exist so it throws me to the home page & I can't seem to find the areticle you are talking about? Could you expand?

Clay:
fsdb, I did have a quick look at this but did not like the warning (words to the effect) "if you use this utility you can irrevacbly loose all the data on your filesystem" - None the less I'm still curious as to how I could re-attach the i-node even if I only ever use it on "test" systems. the man page is a little fuzzy on this.

It look like shut down the process!! Outage time. I'll assign points some time tomorrow

Cheers

Tim

[Knut Eckstein]

All,

Sorry for being extremly late on this thread :-) but I'm the guy who does the port of TCT to HP-UX...and I just stumbled across this discussion via google and would like to quickly add two general points from TCT's perspective:

unrm does not work on the relationship between inode and file name, so it can't be used to reassign another filename to the inode. What unrm does is it collects all data blocks from a filesystem which are marked as free and spits them onto stdout where you then have to sort out the mess using e.g. lazarus. So it's only for recovering file data.

Even if there was a tool that could easily assign a filename to a specific inode number, Unix in general and HP-UX would keep you from doing what Tim wanted to. When the last reference to an inode is removed by rm , the inode's refcount is normally set to zero, but the inode is not marked as free. So the tool would get back to you with an error message saying that that inode was still in use. HP-UX even goes one step further and keeps the refcount at 1, even though there are no references to the inode any more...

So the only way would have been the fsdb, but with unforseable consequences for the application process, who, for the "file removal philosophy" laid out can always safely assume that a file handle he has open remains available for him until he closes it or the process terminates. Evil software uses this property to hide sniffer log files etc. by "removing" them after program startup. So looking back the process shutdown was clearly the best path.

Harry, adding vxfs support is something I keep thinking about, but is is a very large endeavor, because disk layout and internal structures of vxfs are much more complex than HFS. HFS was easy, because from the disk layout it's idential to UFS/Berkeley FFS, which is well documented.
Public information about VxFS is very scarce, only recently I found a book which goes a bit beyond the standard whitepapers: UNIX Filesystems : Evolution, Design, and Implementation by Steve D. Pate. Any additional pointers to documentation would be greatly appreciated.

Best regards,

Knut

[Tim D Fulford]

Many thanks Knut for the reply, super late (over 1 year!!!), but useful none the less. I never actualy got 'round to doing fsdb on anything, good job really!

Regards

Tim

[Josh Caster_1]

Its seems as though its been another year and I would like to know if there has been any progress on this. Basically I have an opened file which was removed and would like to unrm it. Any hp-ux or 3rd party releases? Seems easy enough if the internals were known and I am particularly talking about vfs or onlinejfs.
Thanks
Josh

[Tim D Fulford]

Hi

Hmm, me too.. I never actually tried (actually understood is more accurate) the above.. I was too scared..

[Tim D Fulford]

Hi

I'd like to re-itterate my question, as I've realised there are at least two interpretations
o A file that is STILL ATTACHED to a RUNNING process was removed. Thus the DATA within the file is DEFINITELY still intact, but unaccessable. you can spot these types of situatiions with the tool lsof.
o Someone has done rm and there are NO programs attached to it the file & it's data is destroyed.

I'm only concerned with the first case. This is a common problem e.g. when someone does "rm /var/adm/syslog/syslog.log". What they should have/intended to do is something like "> /var.adm/syslog/syslog.log".. I effectively want to do this data removel AFTER the rm has been issued.
I think Knut Eckstein is talkin partially about this. but I'm still slightly confused .. as Knut mentions a scenario similar to this..
"Evil software uses this property to hide sniffer log files etc. by "removing" them after program startup"

This implies to me the Evil software is able to hide it's log files for latter extraction... Thus I conclude the Evil software must do one of two things
1 - re-attach the i-node to the intact data
2 - attach the data to another i-node for latter extraction.
3 - spool the data into another file (OK this does not help me, as the original data is hidden and this is what I want to delete)

Just to re-itterate, I'm not interested in getting back the data.. I actually want to destroy it!!! (though reserecting the data may be useful for others)

Regards

Tim