>> 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 @no-spam = ("/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
:)