> I know some of the filenames that were in that directory. Is there any > more usable method to find these inodes? for example, i know there was a > symlink drive_c in there, and a file 'snippetz'. Can't i use this to somehow > locate some of the dangling meta information? For sure it can't be all > overwritten... If i grep the partition image for that filename and look up any > resulting blocks with debugfs, is that getting me anywhere nearer the list of > files in that directory? Soo opening the image with hexedit and doing an ascii search for 'snippetz' right at the beginning gave me several locations which look an awful lot like lists of filenames in that directory. Converted the locations to decimal with echo $((16#hexnumber)) those are 0x28E450/0x438A2C0600 (Byte 2679888/290080949760) 0x1125450/0x438A2C0600 (Byte 17978448/290080949760) 0x114F450/0x438A2C0600 (Byte 18150480/290080949760) 0x1219450/0x438A2C0600 (Byte 18977872/290080949760) Now what potential approaches could i take with debugfs now that it seems there are residual pieces of the directory? How to determine the corresponding inodes from the block number (position in bytes / 512, right?) - not clear to me from the man page... regards marcel (slightly more optimistic now). -- Neu: GMX FreeDSL Komplettanschluss mit DSL 6.000 Flatrate + Telefonanschluss für nur 17,95 Euro/mtl.!* http://dslspecial.gmx.de/freedsl-surfflat/?ac=OM.AD.PD003K11308T4569a -- To unsubscribe from this list: send the line "unsubscribe linux-ext4" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
