You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi, I am trying to copy a bunch of old-school macos X icon files that have the icon data set as a resource fork. This is on OSX 13.6.9 with rsync v 3.3.0 (installed via homebrew). The files themselves are 0 bytes. In the following example I am trying to transfer one of these files named "Camebus Blue".
As you can see, it contains 60995 bytes of resource fork.
When I rsync it over to my Unraid server via ssh (with rsync v. 3.3.0 installed), this is what I get as output:
⭕️ oriol@10900k ~ rsync -avP -X /Users/oriol/Desktop/iconsTest/Camebus/Camebus\ Blue [email protected]:/mnt/disk2/test2
sending incremental file list
Camebus Blue
0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
sent 61,213 bytes received 37 bytes 40,833.33 bytes/sec
total size is 0 speedup is 0.00
With more verbose output:
⭕️ oriol@10900k ~ rsync -avvvP -X /Users/oriol/Desktop/iconsTest/Camebus/Camebus\ Blue [email protected]:/mnt/disk2/test2
opening connection using: ssh -l root unraid.local rsync --server -vvvlogDtpXre.iLsfxCIvu --partial . /mnt/disk2/test2 (10 args)
sending incremental file list
[sender] make_file(Camebus Blue,*,0)
send_file_list done
send_files starting
server_recv(2) starting pid=680413
recv_file_name(Camebus Blue)
received 1 names
recv_file_list done
get_local_name count=1 /mnt/disk2/test2
generator starting pid=680413
delta-transmission enabled
recv_generator(test2,1)
send_files(1, /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue)
send_files mapped /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue of size 0
calling match_sums /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue
Camebus Blue
sending file_sum
false_alarms=0 hash_hits=0 matches=0
0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
sender finished /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue
generate_files phase=1
recv_files(1) starting
recv_files(test2)
got file_sum
set uid of .test2.ZLDTle from 0 to 1000
set gid of .test2.ZLDTle from 0 to 20
set modtime, atime of .test2.ZLDTle to (1148180504) 2006/05/21 05:01:44, (1732729280) 2024/11/27 18:41:20
renaming .test2.ZLDTle to test2
send_files phase=1
recv_files phase=1
generate_files phase=2
send_files phase=2
send files finished
total: matches=0 hash_hits=0 false_alarms=0 data=0
recv_files phase=2
recv_files finished
generate_files phase=3
generate_files finished
sent 61,213 bytes received 666 bytes 123,758.00 bytes/sec
total size is 0 speedup is 0.00
[sender] _exit_cleanup(code=0, file=main.c, line=1358): about to call exit(0)
The target filesystem must support the required extended attributes to host these, as if I copy the file manually (from the Finder) to an NFS or SMB mount of the same directory, the extended attributes copied (and the icon itself shows up in the Finder).
Also, note that if I rsync to a local SMB mount of the same dir of the server (instead of connecting through ssh), the extended attributes get copied over OK as well.
⭕️ oriol@10900k ~ rsync -avP -X /Users/oriol/Desktop/iconsTest/Camebus/Camebus\ Blue /Volumes/disk2/test3/
sending incremental file list
created directory /Volumes/disk2/test3
Camebus Blue
0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
sent 61,213 bytes received 80 bytes 122,586.00 bytes/sec
total size is 0 speedup is 0.00
with more verbose:
⭕️ oriol@10900k ~ rsync -avvvP -X /Users/oriol/Desktop/iconsTest/Camebus/Camebus\ Blue /Volumes/disk2/test4/
sending incremental file list
[sender] make_file(Camebus Blue,*,0)
send_file_list done
send_files starting
server_recv(2) starting pid=65625
recv_file_name(Camebus Blue)
received 1 names
recv_file_list done
get_local_name count=1 /Volumes/disk2/test4/
created directory /Volumes/disk2/test4
generator starting pid=65625
delta-transmission disabled forlocal transfer or --whole-file
recv_generator(Camebus Blue,1)
send_files(1, /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue)
send_files mapped /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue of size 0
calling match_sums /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue
Camebus Blue
sending file_sum
false_alarms=0 hash_hits=0 matches=0
0 100% 0.00kB/s 0:00:00 (xfr#1, to-chk=0/1)
sender finished /Users/oriol/Desktop/iconsTest/Camebus/Camebus Blue
generate_files phase=1
recv_files(1) starting
recv_files(Camebus Blue)
got file_sum
set modtime, atime of .Camebus Blue.uu0qgO to (1148180504) 2006/05/21 05:01:44, (1732729785) 2024/11/27 18:49:45
renaming .Camebus Blue.uu0qgO to Camebus Blue
send_files phase=1
recv_files phase=1
generate_files phase=2
send_files phase=2
send files finished
total: matches=0 hash_hits=0 false_alarms=0 data=0
recv_files phase=2
recv_files finished
generate_files phase=3
generate_files finished
sent 61,213 bytes received 697 bytes 123,820.00 bytes/sec
total size is 0 speedup is 0.00
[sender] _exit_cleanup(code=0, file=main.c, line=1358): about to call exit(0)
I don't think this is expected.
The Unraid has this build of rsync:
root@Unraid ~ rsync --version
rsync version 3.3.0 protocol version 31
Copyright (C) 1996-2024 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs,
xattrs, optional secluded-args, iconv, prealloc, stop-at, no crtimes
Optimizations:
SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
xxh128 xxh3 xxh64 (xxhash) md5 md4 sha1 none
Compress list:
zstd lz4 zlibx zlib none
Daemon auth list:
sha512 sha256 sha1 md5 md4
and the macos has this one:
oriol@10900k Camebus rsync --version
rsync version 3.3.0 protocol version 31
Copyright (C) 1996-2024 by Andrew Tridgell, Wayne Davison, and others.
Web site: https://rsync.samba.org/
Capabilities:
64-bit files, 64-bit inums, 64-bit timestamps, 64-bit long ints,
socketpairs, symlinks, symtimes, hardlinks, hardlink-specials,
hardlink-symlinks, IPv6, atimes, batchfiles, inplace, append, ACLs,
xattrs, optional secluded-args, iconv, no prealloc, stop-at, crtimes,
file-flags
Optimizations:
no SIMD-roll, no asm-roll, openssl-crypto, no asm-MD5
Checksum list:
xxh128 xxh3 xxh64 (xxhash) md5 md4 sha1 none
Compress list:
zstd lz4 zlibx zlib none
Daemon auth list:
sha512 sha256 sha1 md5 md4
The text was updated successfully, but these errors were encountered:
Hi, I am trying to copy a bunch of old-school macos X icon files that have the icon data set as a resource fork. This is on OSX 13.6.9 with rsync v 3.3.0 (installed via homebrew). The files themselves are 0 bytes. In the following example I am trying to transfer one of these files named "Camebus Blue".
As you can see, it contains 60995 bytes of resource fork.
When I rsync it over to my Unraid server via ssh (with rsync v. 3.3.0 installed), this is what I get as output:
With more verbose output:
The target filesystem must support the required extended attributes to host these, as if I copy the file manually (from the Finder) to an NFS or SMB mount of the same directory, the extended attributes copied (and the icon itself shows up in the Finder).
Also, note that if I rsync to a local SMB mount of the same dir of the server (instead of connecting through ssh), the extended attributes get copied over OK as well.
with more verbose:
I don't think this is expected.
The Unraid has this build of rsync:
and the macos has this one:
The text was updated successfully, but these errors were encountered: