Bug 6576 - generate_files lists non-existent files
Summary: generate_files lists non-existent files
Alias: None
Product: rsync
Classification: Unclassified
Component: core (show other bugs)
Version: 3.0.8
Hardware: Other Linux
: P3 normal (vote)
Target Milestone: ---
Assignee: Wayne Davison
QA Contact: Rsync QA Contact
Depends on:
Reported: 2009-07-27 08:08 UTC by Lukasz Stelmach
Modified: 2011-01-01 15:03 UTC (History)
0 users

See Also:


Note You need to log in before you can comment on or make changes to this bug.
Description Lukasz Stelmach 2009-07-27 08:08:17 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' / backup@

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:
\ -0
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]
Comment 1 Lukasz Stelmach 2009-07-28 17:48:22 UTC
Further details:

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.
Comment 2 Wayne Davison 2011-01-01 15:03:33 UTC
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.