All of lore.kernel.org
 help / color / mirror / Atom feed
From: Theodore Ts'o <tytso@mit.edu>
To: jon ernst <jonernst07@gmail.com>
Cc: "linux-ext4@vger.kernel.org List" <linux-ext4@vger.kernel.org>
Subject: Re: [1/1] handle e2image offset value better
Date: Sat, 11 Jan 2014 13:43:43 -0500	[thread overview]
Message-ID: <20140111184343.GA20583@thunk.org> (raw)
In-Reply-To: <CAGW2f1ES7Gji4hXEeMzCSdH3VabXU7SeD-4cg4GL6K9ArugwHw@mail.gmail.com>

On Sun, Jan 05, 2014 at 04:42:42AM +0000, jon ernst wrote:
> current e2image cannot handle offset value as 0.
> 
> For example,
> e2image -aro   0 /dev/sda7 ~/e2image7
> will return usage()
> but
> e2image -aro   1 /dev/sda7 ~/e2image7
> is fine.

I'm not seeing a problem;

    cp /dev/null /tmp/foo.img
    mke2fs -t ext4 -F /tmp/foo.img 100
    e2image -aro 0 /tmp/foo.img /tmp/bar.img

Is working just fine for me.

Looking at your patch, I don't think it's correct.  We only want to go
into "move mode" when the user has specified a single argument, and
either the source or destination is non-zero, and of course this
really only makes sense when we are in raw mode.

That's what the code is currently doing.  If I were going to make any
changes, I'd probably change the criteria so that we check to see if
the source and destination offset is identical (since then it's just a
no-op), and we should probably enforce the restriction that we only
allow move mode when the user has specified both the -a and the -r
option.  (Otherwise, they will destroy the data on their file system,
which is probably not the result they were looking for.)

Regards,

						- Ted

  reply	other threads:[~2014-01-11 18:43 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-05  4:42 [PATCH 1/1] handle e2image offset value better jon ernst
2014-01-11 18:43 ` Theodore Ts'o [this message]
2014-01-11 20:08   ` [1/1] " jon ernst

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=20140111184343.GA20583@thunk.org \
    --to=tytso@mit.edu \
    --cc=jonernst07@gmail.com \
    --cc=linux-ext4@vger.kernel.org \
    /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.