extundelete

extundelete-users and developer--

A couple of questions or notes/bugs about extundelete

-- There is mention of '--dump-names' in the help, but no other reference
to it in the source code that I can find.  The developer blog post
http://blog.bisect.de/2011/08/update-for-extundelete.html indicates that
'--dump-names' was added, but.. it doesn't seem to be? Grepping the source
code of 0.2.3 doesn't show any occurence of that text except for the help
text.
I find mention of dump-names being associated with ext3grep, but also find
notes saying that ext3grep is not compatible with ext4.

-- What is the best way to get a list of recoverable and non-recoverable
files that have been deleted? (Is there a way using extundelete?)

-- The restore-directory command is listed on the website and seems to
work, but is not listed in the help file, it seems.

-- Is there a way to get a status during undelete that shows recoverable
and non-recoverable files?  I didn't seem to get any stdout output when
using the --restore-directory option

File system is ext4.

debra@... ~/RECOVERED_FILES/public/cjs/Music/newnonormalrips $
extundelete --help | grep -i restore-directory
debra@... ~/RECOVERED_FILES/public/cjs/Music/newnonormalrips $
extundelete --help | grep -i dump
                         must be one of the paths returned by --dump-names).
debra@... ~/RECOVERED_FILES/public/cjs/Music/newnonormalrips $ s

debra@... ~/RECOVERED_FILES/public/cjs/Music/newnonormalrips $
extundelete -v
extundelete version 0.2.3
libext2fs version 1.42
Processor is little endian.


Thank you!
Camden

Re: [Extundelete-users] dump-names noted in help, but dne in source; --restore-directory in source but dne in help From: <extundelete-users@li...> - 2012-12-28 20:10 Hi Camden, Thanks for your comments.  I have answered below. > >-- There is mention of '--dump-names' in the help, but no other reference to it in the source code that I can find.  The developer blog post http://blog.bisect.de/2011/08/update-for-extundelete.html indicates that '--dump-names' was added, but.. it doesn't seem to be? Grepping the source code of 0.2.3 doesn't show any occurence of that text except for the help text. >I find mention of dump-names being associated with ext3grep, but also find notes saying that ext3grep is not compatible with ext4. > Yes, this looks like it was an oversight.  I don't think dump-names ever worked with extundelete, but I had thought it may be added some day.  When that day came, it seemed like a useless option to me, so I removed the references to it that I could find, but I could still be convinced it could be useful.  I'll give a reason for my thinking in the next answer. > >-- What is the best way to get a list of recoverable and non-recoverable files that have been deleted? (Is there a way using extundelete?) > The best way is to use the --restore-all option and see what files are restored.  In order to determine which files are recoverable, extundelete must actually read the entire file, because if some parts of the file have been overwritten, the file would not be recoverable.  So the only extra overhead would be the writing of the files when compared to an option like what --dump-names would do.  If there was one file you wanted, you could give the path name to --restore-file; If there was one directory, you could give the path to --restore-directory; if you were unsure what the first path name would be, you could use --inode 2 (a trick which may be documented poorly).  debugfs, a part of the e2fsprogs package, may also be able to give more information about the directory structure. > >-- The restore-directory command is listed on the website and seems to work, but is not listed in the help file, it seems.   > I think someone else has noted this oversight.  It will be fixed in the next version. > >-- Is there a way to get a status during undelete that shows recoverable and non-recoverable files?  I didn't seem to get any stdout output when using the --restore-directory option > You may add the option "--log info" to the command line parameters.  Version 0.2.3 probably is too silent, and the next version will output some status messages.  Version 0.2.2 was way too verbose by default. Nic

Re: [Extundelete-users] dump-names noted in help, but dne in source; --restore-directory in source but dne in help From: <extundelete-users@li...> - 2012-12-28 20:56 Attachments: Message as HTML      Thanks, Nic! Couple of things here- For --dump-names, your logic makes sense. I guess the only consideration is if the person has sufficient hard drive space and wants to see what is possible to be recovered. The Logging does work for required output, i found that just a few minutes before you sent this. :) Something I missed is how to identify what files _aren't_ recoverable. The logs indicate the number of non-recoverable inodes, but there is no indication of what files weren't fully recoverable. Am I missing something? Also, does this count of non-recoverable Inodes include the directories, as they are identified with "The inode does not correspond to a regular file"? debra@... /mnt/tmpmnt2 $ grep -v -e Restored -e "does not correspond" cdswap.log WARNING: Extended attributes are not restored. aded. Loading journal descriptors ... 32178 descriptors loaded. Searching for recoverable inodes in directory public/cjs/Music/cdswap ... 6644 recoverable inodes found. Looking through the directory structure for deleted files ... 4370 recoverable inodes still lost. A feature request (or instruction perhaps looking on the net) could be essentially a du --max-depth=1 or similar of deleted files starting at an old path. Again, thanks a ton for the help! Camden

Re: [Extundelete-users] dump-names noted in help, but dne in source; --restore-directory in source but dne in help From: <extundelete-users@li...> - 2012-12-30 19:05 Camden, >Something I missed is how to identify what files _aren't_ recoverable.  The logs indicate the number of non-recoverable inodes, but there is no indication of what files weren't fully recoverable.    Am I missing something?  Also, does this count of non-recoverable Inodes include the directories, as they are identified with "The inode does not correspond to a regular file"? > Any files not recovered by --restore-all are not recoverable to extundelete.  Some files may be only partially recovered; there should be a relevant message if extundelete has found some of those.  There may also be some filenames that extundelete could not know about because they were completely removed.  There is no summary of non-recoverable files output.  The final count of the inodes still lost does not include any of the directories that you see in the log. > >A feature request (or instruction perhaps looking on the net) could be essentially a du --max-depth=1 or similar of deleted files starting at an old path. > If you want to recover the directories, that is just --restore-directory.  If you want the filenames, you can try to run --restore-file with the directory's name and you may get some information about the contents of that directory.  If that doesn't work for you, there is a utility called debugfs (installed along with the rest of e2fsprogs) that probably has a command to show the directory entries.  I'm not familiar enough with it to know the exact command, but it has a good help system. Nic

Re: [Extundelete-users] dump-names noted in help, but dne in source; --restore-directory in source but dne in help From: <extundelete-users@li...> - 2012-12-30 19:08 Attachments: Message as HTML      Understood; Thanks again Nic! Camden On Sun, Dec 30, 2012 at 11:05 AM, <extundelete-users@...: > Camden, > > >Something I missed is how to identify what files _aren't_ recoverable. > The logs indicate the number of non-recoverable inodes, but there is no > indication of what files weren't fully recoverable. Am I missing > something? Also, does this count of non-recoverable Inodes include the > directories, as they are identified with "The inode does not correspond to > a regular file"? > > > > Any files not recovered by --restore-all are not recoverable to > extundelete. Some files may be only partially recovered; there should be a > relevant message if extundelete has found some of those. There may also be > some filenames that extundelete could not know about because they were > completely removed. There is no summary of non-recoverable files output. > The final count of the inodes still lost does not include any of the > directories that you see in the log. > > > > >A feature request (or instruction perhaps looking on the net) could be > essentially a du --max-depth=1 or similar of deleted files starting at an > old path. > > > > > If you want to recover the directories, that is just --restore-directory. > If you want the filenames, you can try to run --restore-file with the > directory's name and you may get some information about the contents of > that directory. If that doesn't work for you, there is a utility called > debugfs (installed along with the rest of e2fsprogs) that probably has a > command to show the directory entries. I'm not familiar enough with it to > know the exact command, but it has a good help system. > > Nic > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnmore_123012 > _______________________________________________ > Extundelete-users mailing list > Extundelete-users@... > https://lists.sourceforge.net/lists/listinfo/extundelete-users >

2 messages have been excluded from this view by a project administrator.