On Fri, Feb 08, 2013 at 07:17:13PM +0100, Ian Kumlien wrote:
> On Fri, Feb 08, 2013 at 06:39:18PM +0100, Goffredo Baroncelli wrote:
> > H Iam,
> >
> > On 02/08/2013 01:36 AM, Ian Kumlien wrote:
> > > This patch includes the functionality of btrfs, it's
> > > found as "btrfs check" however it makes the binary
> > > behave differently depending on what it's run as.
> > [...]
> >
> > >
> > > +static int cmd_dummy(int argc, char **argv)
> > > +{
> > > + return 0;
> >
> > I think we should warn that fsck.btrfs does nothing. Something like:
> > + fprintf(stderr, "WARNING: fsck.btrfs does nothing. "
> > "Try 'btrfs check'\n");
>
> Yes, will do, perhaps not a big warning but atleast alert the user to
> the fact.
I'm not yet decided if I like the no-op functionality merged or if
fsck.btrfs should be a script like fsck.xfs
(http://oss.sgi.com/cgi-bin/gitweb.cgi?p=xfs/cmds/xfsprogs.git;a=blob;f=fsck/xfs_fsck.sh;h=c5a96e688b994c36d9ab1b0206225f2f5e7b12e8;hb=HEAD)
Your version of cmd_dummy is too simple, the mentioned fsck.xfs at least
checks if the device exists, handles the automatic check options and
prints a sensible message what to do if the user runs the utility
expecting it to actually do something.
I think that a binary named 'btrfsck' should be equvalent to 'btrfs
check' for backward compatibility, so I'd take this patch without the
fsck.btrfs bits. Ok?
david
--
To unsubscribe from this list: send the line "unsubscribe linux-btrfs" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
