From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <linux-fsdevel-owner@vger.kernel.org>
Received: from mail-qk0-f194.google.com ([209.85.220.194]:43890 "EHLO
        mail-qk0-f194.google.com" rhost-flags-OK-OK-OK-OK) by vger.kernel.org
        with ESMTP id S1750993AbdJTAy2 (ORCPT
        <rfc822;linux-fsdevel@vger.kernel.org>);
        Thu, 19 Oct 2017 20:54:28 -0400
Received: by mail-qk0-f194.google.com with SMTP id w134so12601662qkb.0
        for <linux-fsdevel@vger.kernel.org>; Thu, 19 Oct 2017 17:54:28 -0700 (PDT)
Date: Thu, 19 Oct 2017 21:54:23 -0300
From: Ernesto =?utf-8?Q?A=2E_Fern=C3=A1ndez?=
        <ernesto.mnd.fernandez@gmail.com>
To: Viacheslav Dubeyko <slava@dubeyko.com>,
        linux-fsdevel@vger.kernel.org
Cc: Ernesto =?utf-8?Q?A=2E_Fern=C3=A1ndez?=
        <ernesto.mnd.fernandez@gmail.com>,
        Hin-Tak Leung <htl10@users.sourceforge.net>,
        Al Viro <viro@zeniv.linux.org.uk>,
        Andreas Gruenbacher <agruenba@redhat.com>,
        Andrew Morton <akpm@linux-foundation.org>
Subject: Re: [PATCH] hfsplus: return ENODATA when no xattr is found
Message-ID: <20171020005422.GA2702@debian.home>
References: <51697605.866452.1508445053840.ref@mail.yahoo.com>
 <51697605.866452.1508445053840@mail.yahoo.com>
 <20171019230246.GA1271@debian.home>
 <1508458513.501.3.camel@dubeyko.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Disposition: inline
Content-Transfer-Encoding: 8bit
In-Reply-To: <1508458513.501.3.camel@dubeyko.com>
Sender: linux-fsdevel-owner@vger.kernel.org
List-ID: <linux-fsdevel.vger.kernel.org>

On Thu, Oct 19, 2017 at 05:15:13PM -0700, Viacheslav Dubeyko wrote:
> On Thu, 2017-10-19 at 20:02 -0300, Ernesto A. Fernández wrote:
> > On Thu, Oct 19, 2017 at 08:30:53PM +0000, Hin-Tak Leung wrote:
> > > 
> > > 
> > > --------------------------------------------
> > > On Thu, 19/10/17, Ernesto A. Fernández <ernesto.mnd.fernandez@gmail
> > > .com> wrote:
> > > 
> > > > 
> > > > There are several points in the code where ENOENT or
> > > > EOPNOTSUPP are
> > > > used to signal that an extended attribute does not exist.
> > > > This is
> > > > clearly noticeable from the odd error messages shown by
> > > > setfattr and
> > > > getfattr. Use ENODATA instead.
> > >  
> > > > 
> > > > Signed-off-by: Ernesto A. Fernández <ernesto.mnd.fernandez@gmail.
> > > > com>
> > > Nacked.
> > > 
> > > I think you perhaps mis-understood the code. Some (older) HFS+ file
> > > system does not have attribute records so it gives  EOPNOTSUPP . It
> > > is not NODATA, but that you cannot write attribute data(or read) to
> > > such old fs. Likewise, the other changes from ENOENT to ENODATA
> > > seems wrong too. "Not found" is not "no data" ( = "found but
> > > null").
> > > 
> > If you create a fresh hfsplus filesystem and run:
> > 
> > touch test
> > setfattr -x user.1 test
> > 
> > you will get an "operation not supported" error. That isn't right.
> > Now
> > if you run:
> > 
> > setfattr -n user.1 test
> > setfattr -x user.1 test
> > setfattr -x user.1 test
> > 
> > you will get a "no such file or directory" error. Also bad, the file
> > is
> > right there. This one is caused by the ENOENT.
> 
> 
> You suggested to exclude all this code (xattr support) from the HFS+
> file system driver. What is the point to review your patches for the
> code that will be deleted? If this code will be deleted then no
> troubles anymore. Forget and relax.

I never suggested anything like that. I'm guessing your confusion is
because of the patch I sent to drop ACL support, but I never spoke of
xattrs.

And you seem to believe it was my idea, but it wasn't. I only wrote
the patch because I was the one who first noticed it was broken a
couple of months ago.

Ernest

> 
> Regards,
> Vyacheslav Dubeyko.
> 
>