Re: [PATCH] hfsplus: return ENODATA when no xattr is found

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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@xxxxxxxxx> 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@xxxxxxxxx>
> 
> 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.



[Index of Archives]     [Linux Ext4 Filesystem]     [Union Filesystem]     [Filesystem Testing]     [Ceph Users]     [Ecryptfs]     [AutoFS]     [Kernel Newbies]     [Share Photos]     [Security]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux Security]     [Linux Cachefs]     [Reiser Filesystem]     [Linux RAID]     [Samba]     [Device Mapper]     [CEPH Development]
  Powered by Linux