On Sat, Feb 09, 2013 at 12:07:50AM +0100, David Sterba wrote:
> 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?
Thats fine by me, =)
I didn't know that fsck.xfs did that and i agree that it's a much saner
approach, should we do something similar already or just put it in tha
backlock for when it might be... or, when it would actually be usefull?
> 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
