Hmm yeah. First attempt issuing a fsck.ext3 -yv /dev/sdd4 resulted in a lost+found frenzy - everything under the former directory /mnt/sdc4/homedirs/currenthomebase (which was mounted under /home) got relinked into lost+found with sequential numbers... Not bad, the data is there - but this is quite unusable iykwim.. > Now that you have a backup copy, I'd suggest to get that "but sdd4 is > mounted" error out of the way and try to e2fsck with a different > superblock. Uhmm, well. So i again dded the backup image to the partition, ran mkfs.ext3 -nv /dev/sdd4 to get a list of the FS's backup superblocks, then tried to see if any of them is in a better state than the original one by doing > for blockpos in 32768 98304 163840 229376 294912 819200 884736 1605632 > 2654208 4096000 7962624 11239424 20480000 23887872; do fsck.ext3 -vnb > $blockpos /dev/sdd4 > fsck-$blockpos.log; done and then comparing those output files. Unfortunately, all show the same resulting output meaning there is no benefit from using them. A script i found @ http://blog.windfluechter.net/index.php?/archives/307-Automatically-restore-files-from-lost+found-improved.html which can move objects back in place from lost+found has to backup all filenames BEFORE running into this situation so is not of great help at this point.. Oh and this extundelete tool - i couldn't quite put it to the test because as soon as i let it loose on the partition - well it quickly eats up all memory causing the oom_killer to terminate it. Force-mounting the partition _without_ repairing it just results in an empty mount point. Ain't there no alternative way to reconstruct the directory structure, it surely can't be overwritten completely...?? regards marcel. -- Psssst! Schon vom neuen GMX MultiMessenger gehört? Der kann`s mit allen: http://www.gmx.net/de/go/multimessenger01 -- 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
