[Bug 10290] Regression since 3.0.9: send_xattr_request: Assertion `f_out >= 0' failed

samba-bugs at samba.org samba-bugs at samba.org
Tue Dec 31 05:26:59 MST 2013


--- Comment #5 from Moritz Bunkus <moritz at bunkus.org> 2013-12-31 12:26:56 UTC ---
Unfortunately I haven't been able to narrow down the test case. I've spent the
last couple of days trying to make it as small as possible. The bug occurs when
I rsync a whole dirvish host directory (beneath the host directory there is one
directory per day when a backup was run, and beneath those is a tree of the
whole backed up file system from that day hard-linked to the previous day's

It also happens for the same file each and every time (I've run »rsync
-vvhaxHAX --delete src/ dest/« and the last file name output before that
assertion has been the same each and every time). Apart from the files having a
moderate hard link count (~ 28) I cannot find anything special about it. As a
matter of fact it happens with a file from Dropbox' cache directory

As soon as I try to narrow down the test case the bug disappears. What I've
tried is to move all the .dropbox.cache directories out from their huge dirvish
structure into a new directory structure that was laid out the same as the
dirvish structure. For example, orignal file structure:
similar names for other days; temporary structure:
I've only moved each and every .dropbox.cache directory there was in the
original structure to its place in the temporary structure; no other
directories were populated in the temp structure.

I reasoned that those Dropbox cache files should only have hard links to files
in the other Dropbox cache directories but not to any normal file outside of
those directories.

Unfortunately as soon as I rsync'ed that temporary structure the assertion
wasn't triggered.

Now I'm out of ideas of how to narrow it down. If you have any please let me
know and I'll give them a try.

Configure bugmail: https://bugzilla.samba.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the QA contact for the bug.

More information about the rsync mailing list