Steven Kilby
2017-Jan-03 15:16 UTC
Inconsistent behavior using 3.1.2 from macOS 10.12.2 to an AFP mount
Hi, I've been attempting to use rsync 3.1.2 to copy files from a macOS 10.12.2 system to an AFP mounted share. The command I'm using is: rsync -avAX -M--fake-super ./testDir ./mnt/testDir/ This works fine and all the extended attributes are copied and readable. I then try to use rsync to copy these files back with: rsync -avAX --fake-super -M--super ./mnt/testDir/ ./testDir2/ This outputs errors such as: rsync: get_xattr_data: lgetxattr(""./mnt/testDir/./testFile2"","com.apple.quarantine",0) failed: Attribute not found (93) When I use a few -vvv this pattern is present: [sender] pushing local filters for ./mnt/testDir/ [sender] make_file(testFile1,*,2) [sender] expand rsync_xa to 40 bytes, did move [sender] make_file(testFile2,*,2) rsync: get_xattr_data: lgetxattr("" .... The com.apple.quarantine attribute is on testFile1 and so of course it is "not found" on the second file. The first file was copied without any extended attributes. It appears that somehow rsync loses track of what file has the attributes. Has anyone seen this before? This happens every time when going from the AFP mount to the mac. I don't see this when I mount the same folder using SMB. I've seen this one time and only one time when going from the mac to the share. Steven -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20170103/bf39e969/attachment.html>
Everett Batey
2017-Jan-03 21:44 UTC
Inconsistent behavior using 3.1.2 from macOS 10.12.2 to an AFP mount
Assuming you are aware Apple 10.12.1/2 did a number on crypto, broke SSH, HTTPS to "legacy" servers. R/ Everett Batey / Skype: wa6cre-10 / efbatey at gmail.com Please visit So Calif Linux Expo http://www.socallinuxexpo.org On Tue, Jan 3, 2017 at 7:16 AM, Steven Kilby <stevenkilby2 at gmail.com> wrote:> Hi, > > I've been attempting to use rsync 3.1.2 to copy files from a macOS 10.12.2 > system to an AFP mounted share. The command I'm using is: > > rsync -avAX -M--fake-super ./testDir ./mnt/testDir/ > > This works fine and all the extended attributes are copied and readable. > > I then try to use rsync to copy these files back with: > > rsync -avAX --fake-super -M--super ./mnt/testDir/ ./testDir2/ > > This outputs errors such as: > > rsync: get_xattr_data: > lgetxattr(""./mnt/testDir/./testFile2"","com.apple.quarantine",0) failed: > Attribute not found (93) > > When I use a few -vvv this pattern is present: > > [sender] pushing local filters for ./mnt/testDir/ > [sender] make_file(testFile1,*,2) > [sender] expand rsync_xa to 40 bytes, did move > [sender] make_file(testFile2,*,2) > rsync: get_xattr_data: lgetxattr("" .... > > The com.apple.quarantine attribute is on testFile1 and so of course it is > "not found" on the second file. The first file was copied without any > extended attributes. > > It appears that somehow rsync loses track of what file has the attributes. > Has anyone seen this before? This happens every time when going from the > AFP mount to the mac. I don't see this when I mount the same folder using > SMB. I've seen this one time and only one time when going from the mac to > the share. > > Steven > > -- > 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 >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20170103/0503c7ef/attachment.html>
Steven Kilby
2017-Jan-04 13:58 UTC
Inconsistent behavior using 3.1.2 from macOS 10.12.2 to an AFP mount
Hi - yes, but I didn't think that would be an impact. I'm running rsync locally using a mounted file share. AFP iSnt encrypted right? On Tue, Jan 3, 2017 at 4:44 PM Everett Batey <efbatey at gmail.com> wrote:> Assuming you are aware Apple 10.12.1/2 did a number on crypto, broke SSH, > HTTPS to "legacy" servers. > > R/ Everett Batey / Skype: wa6cre-10 / efbatey at gmail.com > Please visit So Calif Linux Expo http://www.socallinuxexpo.org > > > > On Tue, Jan 3, 2017 at 7:16 AM, Steven Kilby <stevenkilby2 at gmail.com> > wrote: > > Hi, > > I've been attempting to use rsync 3.1.2 to copy files from a macOS 10.12.2 > system to an AFP mounted share. The command I'm using is: > > rsync -avAX -M--fake-super ./testDir ./mnt/testDir/ > > This works fine and all the extended attributes are copied and readable. > > I then try to use rsync to copy these files back with: > > rsync -avAX --fake-super -M--super ./mnt/testDir/ ./testDir2/ > > This outputs errors such as: > > rsync: get_xattr_data: > lgetxattr(""./mnt/testDir/./testFile2"","com.apple.quarantine",0) failed: > Attribute not found (93) > > When I use a few -vvv this pattern is present: > > [sender] pushing local filters for ./mnt/testDir/ > [sender] make_file(testFile1,*,2) > [sender] expand rsync_xa to 40 bytes, did move > [sender] make_file(testFile2,*,2) > rsync: get_xattr_data: lgetxattr("" .... > > The com.apple.quarantine attribute is on testFile1 and so of course it is > "not found" on the second file. The first file was copied without any > extended attributes. > > It appears that somehow rsync loses track of what file has the attributes. > Has anyone seen this before? This happens every time when going from the > AFP mount to the mac. I don't see this when I mount the same folder using > SMB. I've seen this one time and only one time when going from the mac to > the share. > > Steven > > > > -- > > > 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 > >-------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.samba.org/pipermail/rsync/attachments/20170104/a15598a8/attachment.html>
Seemingly Similar Threads
- Inconsistent behavior using 3.1.2 from macOS 10.12.2 to an AFP mount
- scp forces original access permissions when owner lacks write access
- ACL bug
- behavior of ALU Scheduler
- DO NOT REPLY [Bug 4220] New: --backup causes "stat" failed message when trying to delete a directory