My sincere apologies. It would appear that I was overly careful about
checking the binary functioned when called as a symlink, but not the
correct filename:

  # ls -l `which fsck.btrfs`
  lrwxrwxrwx 1 root root 7 Aug 25  2011 /sbin/fsck.btrfs -> btrfsck

So yes, the patch incorrectly assumed a symlink name of
'fsck.btrfsck', instead of 'fsck.btrfs'.

As for fsck.xfs, I will take a look, thanks!


On Mon, Apr 15, 2013 at 10:03 AM, Jan Alexander Steffens
<jan.steff...@gmail.com> wrote:
>
> On Mon, Apr 15, 2013 at 3:47 PM, Dan McGrath <danmcgrath...@gmail.com> wrote:
> > As per FAQ: It is safe to and recommended to turn fsck.btrfs into a no-op
> >
> > Signed-off-by: Dan McGrath <danmcgrath...@gmail.com>
> > ---
> >  btrfs.c |    2 ++
> >  1 file changed, 2 insertions(+)
> >
> > diff --git a/btrfs.c b/btrfs.c
> > index 691adef..78161a9 100644
> > --- a/btrfs.c
> > +++ b/btrfs.c
> > @@ -272,6 +272,8 @@ int main(int argc, char **argv)
> >
> >         if (!strcmp(bname, "btrfsck")) {
> >                 argv[0] = "check";
> > +       } else if (!strcmp(bname, "fsck.btrfsck")) {
> > +               exit(0);
> >         } else {
> >                 argc--;
> >                 argv++;
> > --
> > 1.7.9.5
> >
> > --
> > 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
>
> Shouldn't it be fsck.btrfs, not fsck.btrfsck?
>
> Also, fsck.xfs does a bit more than just an exit(0), maybe there's
> some merit to what it does. It's a simple shellscript, so check it
> out.
--
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

Reply via email to