All of lore.kernel.org
 help / color / mirror / Atom feed
From: Felipe Monteiro de Carvalho <felipemonteiro.carvalho@gmail.com>
To: xfs@oss.sgi.com
Subject: Recovery of deleted files/directories
Date: Thu, 7 Aug 2014 15:41:57 +0200	[thread overview]
Message-ID: <CACyNnZNAZUSf1Veybw24hU0snaTyp+Yg+wXS1_Kv-rynQjzjuw@mail.gmail.com> (raw)

On Thu, Aug 7, 2014 at 2:56 PM, Brian Foster <bfoster@redhat.com> wrote:
>> But di_mode in particular is a key element as I am using it to
>> differentiate files from directories.
> In general you can't rely on on-disk data once the inode has been freed.
> Perhaps you should start a new thread with some kind of write up about
> what you're trying to accomplish and how you're going about it.

Yes, I know it is unreliable, and that's OK for me. I'm satisfied in
having a best effort solution which works often, it does not have to
be fully reliable.

What I am trying to accomplish is quite simple: Recover as many
deleted files in a XFS partition as possible. For example if someone
deletes a file by mistake, how to get it back?

And the current place where I got stuck is exactly the post-xfs_ifree
inode, specifically deciding if the inode is a directory or a file. In
my hex editor I see that all the information is still there, it would
be a petty to give up when so little is missing.

That di_format is overwritten is a big problem too, but I think I can
work around it by trying each format and choose the best result from
all tries.

Also, I just noticed that di_size is also overwritten ... which will
be very bad for file recovery.

But knowing if the inode is a file or a directory is the most pressing issue.

For a better illustration, here is the data I see for a directory
(xfs_del is the deleted, xfs_orig is before delete):

http://magnifier.sourceforge.net/temp/xfs/xfs_deleted_inode_dir.png

And the same for a file:

http://magnifier.sourceforge.net/temp/xfs/xfs_deleted_inode_file.png

Well, it might be that what I want to do is impossible, but I just I
might ask in case anyone knows any other way to differentiate a file
from a directory, if at least this information is present I could
somehow work around the other issues.

thanks,
-- 
Felipe Monteiro de Carvalho

_______________________________________________
xfs mailing list
xfs@oss.sgi.com
http://oss.sgi.com/mailman/listinfo/xfs

             reply	other threads:[~2014-08-07 13:42 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-08-07 13:41 Felipe Monteiro de Carvalho [this message]
2014-08-07 14:45 ` Recovery of deleted files/directories Eric Sandeen
2014-08-08  8:54   ` Felipe Monteiro de Carvalho

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CACyNnZNAZUSf1Veybw24hU0snaTyp+Yg+wXS1_Kv-rynQjzjuw@mail.gmail.com \
    --to=felipemonteiro.carvalho@gmail.com \
    --cc=xfs@oss.sgi.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.