The Samba-Bugzilla – Bug 6576
generate_files lists non-existent files
Last modified: 2011-01-01 15:03:33 UTC
When I run rsync -X (see below) remote rsync reports (xattrs.c:159):
rsync: get_xattr_names: llistxattr("etc",1024) failed: No such file or directory (2)
the command I enter to start rsync is:
/usr/bin/rsync -aXn --stats --delete --iconv=iso8859-2,utf-8 --link-dest=../1 --password-file /root/rsync/rsync.backup.cred --filter='. /root/rsync/system.exclude' / email@example.com::vlana/0
vlana module on the remote machine is configured as:
path = /mnt/sdf1/vlana
comment = Backup space for Vlana
read only = false
fake super = false
uid = root
auth users = backup
secrets file = /etc/rsyncd.secrets
charset = utf8
when the remote rsync starts it does does:
chroot("/mnt/sdf1/vlana") = 0
chdir("/") = 0
llistxattr("etc", 0x80e2368, 1024) = -1 ENOENT (No such file or directory)
Which is pointless because the directory tree looks like this:
and so on.
The numbered directories are incremental hard-linked backups made each day and
there won't be "etc" next to 0,1,2. I assume it should be either "1/etc" (because of --link-dest) or "0/etc". Why rsync omits either prefix?
At the moment I receive the message the stack on the remote machine looks like this:
[bt] Execution path:
[bt] /mnt/sdf1/rsync/rsync(show_stackframe+0x2d) [0x8085ef4]
[bt] /mnt/sdf1/rsync/rsync [0x8086045]
[bt] /mnt/sdf1/rsync/rsync [0x8086327]
[bt] /mnt/sdf1/rsync/rsync(get_xattr+0x4c) [0x80866f8]
[bt] /mnt/sdf1/rsync/rsync(itemize+0x30f) [0x805b61f]
[bt] /mnt/sdf1/rsync/rsync [0x805da53] <-- this is recv_generator
[bt] /mnt/sdf1/rsync/rsync(generate_files+0x45c) [0x80604c4]
[bt] /mnt/sdf1/rsync/rsync [0x806c9f0]
[bt] /mnt/sdf1/rsync/rsync [0x806cdf3]
[bt] /mnt/sdf1/rsync/rsync(start_server+0xbd) [0x806cefd]
[bt] /mnt/sdf1/rsync/rsync [0x808dceb]
[bt] /mnt/sdf1/rsync/rsync(start_daemon+0x2ad) [0x808e0ad]
[bt] /mnt/sdf1/rsync/rsync(start_accept_loop+0x2c9) [0x8080f63]
[bt] /mnt/sdf1/rsync/rsync(daemon_main+0x14e) [0x808e40e]
[bt] /mnt/sdf1/rsync/rsync(main+0x487) [0x806e04d]
[bt] /lib/libc.so.6(__libc_start_main+0xe0) [0xb7df6390]
[bt] /mnt/sdf1/rsync/rsync [0x8050841]
0. The problem is also when doing local rsync.
1. The same happens for ACLs (-A):
rsync: get_acl: sys_acl_get_file(home, ACL_TYPE_ACCESS): No such file or directory (2)
2. This seems to have something to do with --link-dest
3. The process that fails to get ACL or EA works in the directory rsync has been started from. It is the first child of the master process (master's PID+1).
4. It is not 100% reproducible. Rsyncing different directories may work. However, when the problem occurs with a particular directory it happens every time. The strange thing is that rsync does not query EA (llistxattr)
When I start rsync from the directory I give as --link-dest I don't get any warnings. Or should I start at the source directory? Either way the process should chdir() automatically.
The error message was outputting the filename relative to the transfer, so it was talking about 0/etc. In the case where directory 0/etc did not exist but alt-dest 1/etc did exist, rsync was itemizing director xattrs always against the real destination, which could cause an error if the destination directory did not yet exist.
I have changed the error messages for xattrs to output a full path (as other errors do) and have fixed this itemizing xattr lookup to check against the alt-path directory. This will be in 3.0.8.