>> now that i've looked at it, it's really for getting to files that are >> unlinked etc..... so i am not sure it will do you any good. > >Partly it might. The only problem with your script is that it cannot >deal with data that is spanning more than 12 inodes (those were usually >not in one block but fragmented over the harddisk). A line like this >shows such a trickier example: > > 99526 0 100644 676132 1/1027 Sat Feb 2 09:11:58 2002 > >I don't by hard know what to do with it, but it is laid out in the ext2 >undeletion how-to.
well, the undeletion howto is a little old (1999) but interesting to look through... http://tldp.org/HOWTO/Ext2fs-Undeletion.html#toc9 > >> to bring this more on topic, i would like to see what ways something like >> this can be improved- it served useful to me in the past, but i'm sure it >> can be made more useful::: >> >> >> #!/usr/bin/perl >> >> # added proper things when retyping it: >> use warnings; >> use diagnostics; >> use strict; >> #------------------- >> >> my $cfile = "/tmp/commands.file"; >> my $filesystem ="/dev/hda6"; >> my @path = ("/tmp/recover","","/recover","",".ebu"); #making a path to >put >> my $date="Oct"; #just files from October #stuff later >> >> open (OUT,">$cfile"); >> print OUT "open $filesystem\n";# i wonder what this is for? > >Debug message? > no! :) debugfs -f /filepath :) open opens the filesystem without mounting it... then dump does its thing- all inside debugfs!! > >command.file is the list of dump directives. It's supposedly a shell >script that you can run later. So the above Perl script just generates >another script. I am just not sure about > >> print OUT "open $filesystem\n"; > > open /dev/hda6 > >is not a meaningful command in shell scripts AFAIK. and the mystery is solved!!! now i would like to look into using this to make a perl script to automate file recovery.... well, someday at anyrate! willy :) -- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
