linux-ext4.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: Prashant Shah <pshah.mumbai@gmail.com>
Cc: linux-ext4@vger.kernel.org
Subject: Re: Dump file inode information from ext2/3 partition
Date: Thu, 23 Aug 2012 15:39:04 -0400	[thread overview]
Message-ID: <20120823193904.GA6234@thunk.org> (raw)
In-Reply-To: <CAD6i1fJF5wcX2dj2P8mUR4J5Qz3x58CiSfzubYoy0b1ZcRYcRw@mail.gmail.com>

On Thu, Aug 23, 2012 at 07:43:29PM +0530, Prashant Shah wrote:
> 
> We wrote a small tool to dump file inode information from ext2/3
> partition as an assignment related to learning about file systems.
> 
> https://github.com/prashants/tools/tree/master/ext
> https://github.com/prashants/tools/blob/master/ext/ext3dump.c
> 
> I am not sure if there is any future use for it other than for
> learning purposes.

I hope it was enjoyable learning how to access an ext2/3 filesystem
directly!

Some comments about your code:

*) It requires that the file system be mounted (so you can get the
   inode number), and then it accesses the file directly through the
   block device.  This is a no-no, since the block might not have been
   flushed out to disk yet if it was a newly created file.

*) You don't check that the inode number that you got by using
   open()/stat() is from the same file system that you are accessing
   via the block device.

*) You don't check to see if the filesystem feature flags are as you
   expect; this utility will blow up pretty spectacularly on an ext4
   file system.

If you want to see how a better version of this functionality can be
built, please see the "debugfs" program which is part of e2fsprogs.
It uses the libext2fs libraries, and is a much more robust program for
direct access to a file system via the block device for debugging
purposes.

If you want to see a more user-friendly interface, please take a look
at the e2tools package.  It also uses the libext2fs library which is
distributed as part of e2fsprogs (and installed on pretty much all
Linux distributions), and is a more polished way of accessing a file
directly meant to be used by end users --- as opposed to debugfs,
which is really meant for file system engineers.

So debugfs is more powerful, but you can also do severe harm to the
file system if you open the filesystem read/write and you start
messing with it.  At the same time, debugfs is also a more interesting
if you are a student who wants to get a much better understanding of
the underlying file system format.

Regards,

						- Ted

      reply	other threads:[~2012-08-23 19:39 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-08-23 14:13 Dump file inode information from ext2/3 partition Prashant Shah
2012-08-23 19:39 ` Theodore Ts'o [this message]

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=20120823193904.GA6234@thunk.org \
    --to=tytso@mit.edu \
    --cc=linux-ext4@vger.kernel.org \
    --cc=pshah.mumbai@gmail.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).