Hello all, please see http://www.isd.uni-stuttgart.de/~eckstein/tct-hp.html for the third release of my HP-UX port, introducing support for 11.00 and now including tctutils-1.01. For 10.20, a bug that made "grave-robber -I" fail was fixed. This release *should* also compile and run nicely on 11.11. I'd be happy to hear from anyone who gives this a try. Please note that the low-level file-system tools like unrm, ils and icat only work with HFS, HP's incarnation of the Berkeley FFS. HP-UX also knows the journaling filesystems VxFS and OnlineJFS, the latter being a pay-extra extension of the former. Both are proprietary products of Veritas Inc. which are not publicly documented. There have been several analysis effords resulting in a read-only Linux kernel driver for VxFS, which could provide a starting point for adding VxFS support to TCT, but this is a complex issue, so don't hold your breath :-) Yes, I know that tctutils is no longer maintained, I mainly did the port out of curiousity, to understand it's basic mechanisms of operation (and to provide hints for Brian for porting TASK to HP-UX :-). The interesting and disappointing thing that I found out about HP-UX is that when deleting a directory entry, it not only removes the inode number, but also the name string. That means you can't find out anything about deleted file names, neither with fls nor with "strings <dirname>" nor with bcat etc... Like with 10.20, I tested unrm on 11.00 on a file > 2GB. While waiting almost three hours during the unrm run, I thought I should analyze the output of unrm to see how contiguously that file was stored on the disk. Quite a few people look at unrm and hope to be able to undelete arbitrary files that they accidentially deleted. IMHO, success in undeletion highly depends on how contiguously a file is stored on disk, because you have to indentify the chunks in the output of unrm/lazarus and glue the together in the right order. My basic assumption was, since for FFS-type filesystems rotdelay is 0 by default (see man tunefs), and cylinder groups are switched when 25% of the capacity of a group is reached, that a large file would be broken into chunks the size of 25% of a cylinder group. So I was expecting around 800 2.5 MB chunks for my 2.1 GB file on a filesystem with 10 MB cylinder group size. What I found were 1849 chunks (300+ around 2.5 MB but 500+ at 8 KB!) A detailed description of my experiment and two quite suprising (at least for me) plots illustrating the allocation strategy that I observed can be found on http://www.isd.uni-stuttgart.de/~eckstein/tct-hp-unrm.html Any comments/explanations on this are highly appreciated. Have fun, Knut ----------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Sat Aug 03 2002 - 19:28:49 PDT