Operation not supported (95)

[Kay-24]

Hi guys,

I'm running into a problem that I'm sure which part of the process
fails.   I use wget (OSX Leopard, wget 3.0.6 compiled from source) to
backup my ~/Pictures directory to a linux server, also with wget 3.0.6
(Debian).  In persuit of being sure I get everything from HFS filesystem
(resource fork/metadata), I'm getting the following error:

rsync: rsync_xal_set:
lsetxattr("Pictures/...[snip].../IMG_7766/IMG_7766.dng","user.com.apple.FinderInfo")
failed: Operation not supported (95)

I have search through the archives and only found this error in what
seemed to be an error relating to selinux (which I'm not using).  The
target filesystem is ext3 with acl enabled.  The file is written, but
obviously setting the extended attributes fail.   I'm using the
following command:

/usr/local/bin/rsync -avz --xattrs --acls --hard-links --fake-super
--delete --exclude */Samples/* -e ssh /Users/kay/Pictures
kay@...:/pictures/

I guess the question is two-fold:

1.  Am I expecting something that rsync cannot deliver, i.e. storing the
HFS+ specific stuff on an EXT3 filesystem? For information sake, the
same command between two HFS+ filesystems (on the same box) doesn't
produce any errors.  I was under the impression that the above command
saves  the metadata/xattrs in a format that rsync can read back and pass
back to OSX/HFS+

2.  What exactly is the above error telling me? I mean, what is it
trying to do which isn't supported?

Thanks
Kay
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[Matt McCutchen-7]

On Wed, 2009-10-28 at 18:55 +0000, Kay wrote:

> I'm running into a problem that I'm sure which part of the process
> fails.   I use wget (OSX Leopard, wget 3.0.6 compiled from source) to
> backup my ~/Pictures directory to a linux server, also with wget 3.0.6
> (Debian).  In persuit of being sure I get everything from HFS filesystem
> (resource fork/metadata), I'm getting the following error:
>
> rsync: rsync_xal_set:
> lsetxattr("Pictures/...[snip].../IMG_7766/IMG_7766.dng","user.com.apple.FinderInfo")
> failed: Operation not supported (95)
>
> I have search through the archives and only found this error in what
> seemed to be an error relating to selinux (which I'm not using).  The
> target filesystem is ext3 with acl enabled.

Does the target filesystem have user extended attributes enabled with
the "user_xattr" mount option?  If not, rsync would get "Operation not
supported" when it tries to set them.

--
Matt

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[Kay-24]

Matt McCutchen wrote:

> On Wed, 2009-10-28 at 18:55 +0000, Kay wrote:
>> I'm running into a problem that I'm sure which part of the process
>> fails.   I use wget (OSX Leopard, wget 3.0.6 compiled from source) to
>> backup my ~/Pictures directory to a linux server, also with wget 3.0.6
>> (Debian).  In persuit of being sure I get everything from HFS filesystem
>> (resource fork/metadata), I'm getting the following error:
>>
>> rsync: rsync_xal_set:
>> lsetxattr("Pictures/...[snip].../IMG_7766/IMG_7766.dng","user.com.apple.FinderInfo")
>> failed: Operation not supported (95)
>>
>> I have search through the archives and only found this error in what
>> seemed to be an error relating to selinux (which I'm not using).  The
>> target filesystem is ext3 with acl enabled.
>
> Does the target filesystem have user extended attributes enabled with
> the "user_xattr" mount option?  If not, rsync would get "Operation not
> supported" when it tries to set them.

If it was a snake.... Thanks!  That error is gone now.   New ones
appeared though:

rsync: rsync_xal_set: lsetxattr("Pictures/...[snip].../DSC00948
(1)/DSC00948.JPG","user.com.apple.ResourceFork") failed: No space left
on device (28)

There certainly is space left - about 130GB.  Inodes aren't used up
either and other files continues to copy after this.  While I haven't
found the exact cause of the error, in my search I did find some
suggestions that XFS is a better choice for backing up from HFS+, so I
tried that and this error disappeared.

This one remains though:

rsync: rsync_xal_set: lsetxattr("Pictures/...[snip].../IMG_0960
(2)/IMG_0960.tiff","user.com.apple.ResourceFork") failed: Argument list
too long (7)
rsync: rsync_xal_set:
lsetxattr("Pictures/...[snip].../Image0001.TIF","user.com.apple.ResourceFork")
failed: Argument list too long (7)
rsync: rsync_xal_set:

Thanks
Kay
--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html

[Matt McCutchen-7]

On Thu, 2009-10-29 at 21:11 +0000, List Reader wrote:

> While I haven't
> found the exact cause of the error, in my search I did find some
> suggestions that XFS is a better choice for backing up from HFS+, so I
> tried that and this error disappeared.
>
> This one remains though:
>
> rsync: rsync_xal_set: lsetxattr("Pictures/...[snip].../IMG_0960
> (2)/IMG_0960.tiff","user.com.apple.ResourceFork") failed: Argument list
> too long (7)
> rsync: rsync_xal_set:
> lsetxattr("Pictures/...[snip].../Image0001.TIF","user.com.apple.ResourceFork")
> failed: Argument list too long (7)

It looks like you've hit a limit on the size of the attribute value.  I
tested on both xfs and reiserfs and saw a limit at exactly 65536 bytes;
I don't know whether this is a coincidence or the limit is actually in
Linux.

I don't see an easy way around this, so your options would be:

1. Figure out whether you actually need the massive resource-fork data:
make a copy of the source file, run "setfattr -x com.apple.ResourceFork"
on the copy, and see if you've lost anything important.  If not, just
keep the stripped file.

2. If you do need the resource fork, you could have your backup script
split the file into a plain data file and a separate file with the xattr
information, using the "xattr" command or something that will make a
standard AppleDouble file if you like that.  Put the plain data file in
a separate tree and add that tree as the first source argument to rsync,
so that the plain data file overlays the original and rsync won't get
xattr errors.  Reply if you want to take this approach and need more
help.

--
Matt

--
Please use reply-all for most replies to avoid omitting the mailing list.
To unsubscribe or change options: https://lists.samba.org/mailman/listinfo/rsync
Before posting, read: http://www.catb.org/~esr/faqs/smart-questions.html