On Thu, 2015-04-02 at 19:57 -0400, Thomas Hebb wrote: > > Could you describe in more details how do you use userspace utilities > > for extracting xattr? > > Of course. I first create a new file on an HFS+ filesystem (case- > sensitive, journaling disabled). I then call listxattr() on that > file and receive a list of one attribute: > osx.com.apple.FinderInfo > I call getxattr() with this name as the second argument. > > Without the patch, getxattr() returns -1 and sets errno to either > ENOATTR (ENODATA) if the volume has an attribute tree or EOPNOTSUPP if > it doesn't. This behavior is clearly wrong, since listxattr() told me > that the attribute existed. > > In the case where ENOATTR is returned (when an attribute b-tree exists, > as it does when any file on the filesystem has a real attribute), the > error causes GNU patch 2.7.5 to fail with the error message > getting attribute osx.com.apple.FinderInfo of osx.com.apple.FinderInfo: No data available > (As shown in the attached typescript.) That's how I originally discovered > the problem. > > I have written a test program to demonstrate the issue. It builds on > both Linux and OS X, so that the behaviors can be compared. You can > find it at https://github.com/tchebb/xattr-test. OK. Thank you. I need to check that xattr support doesn't work for HFS+ now. It worked pretty well earlier. Thanks, Vyacheslav Dubeyko. -- To unsubscribe from this list: send the line "unsubscribe stable" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html