hardlink bug in 2.6.4?

[Erik Jan Tromp]

On Fri, 22 Apr 2005 09:08:38 -0700
Wayne Davison <wayned at samba.org> wrote:

First up, sorry about the dup'd post.. just me being braindead at that hour.

> It would help to know what rsync was doing with the files when the error
> happened, if all the hard-links for a particular hard-link group are
> represented in the errors, and what the results were after the transfer.
> 
> The error messages reveal these files, separated into linked groups:
> 
>     slackware-10.0/source/d/cvs/slack-desc
>     slackware-10.1/patches/source/cvs/slack-desc
> 
>     slackware-10.0/source/d/python/slack-desc
>     slackware-10.1/patches/source/python/slack-desc
>     slackware-8.1/patches/source/python/slack-desc
>     slackware-9.0/patches/source/python/slack-desc
>     slackware-9.1/patches/source/python/slack-desc
> 
>     slackware-10.0/source/d/python/slack-desc.python-demo
>     slackware-10.1/patches/source/python/slack-desc.python-demo
>     slackware-10.0/patches/source/python/slack-desc
> 
>     slackware-10.0/source/d/python/slack-desc.python-tools
>     slackware-10.1/patches/source/python/slack-desc.python-tools
>     slackware-9.1/patches/source/python/slack-desc.python-tools
> 
> - Are any other files (that were not excluded from the transfer) hard-
>   linked to these files?

Going by inodes, here's what I came up with (grouped as above):

slackware-10.0/patches/source/cvs/slack-desc
slackware-10.0/source/d/cvs/slack-desc
slackware-10.1/patches/source/cvs/slack-desc
slackware-10.1/source/d/cvs/slack-desc
slackware-8.1/patches/source/cvs/slack-desc
slackware-8.1/source/d/cvs/slack-desc
slackware-9.0/patches/source/cvs/slack-desc
slackware-9.0/source/d/cvs/slack-desc
slackware-9.1/patches/source/cvs/slack-desc
slackware-9.1/source/d/cvs/slack-desc
slackware-current/source/d/cvs/slack-desc

slackware-10.0/patches/source/python/slack-desc
slackware-10.0/source/d/python/slack-desc
slackware-10.1/patches/source/python/slack-desc
slackware-10.1/source/d/python/slack-desc
slackware-8.1/patches/source/python/slack-desc
slackware-8.1/source/d/python/slack-desc
slackware-9.0/patches/source/python/slack-desc
slackware-9.0/source/d/python/slack-desc
slackware-9.1/patches/source/python/slack-desc
slackware-9.1/source/d/python/slack-desc
slackware-current/source/d/python/slack-desc

slackware-10.0/patches/source/python/slack-desc.python-demo
slackware-10.0/source/d/python/slack-desc.python-demo
slackware-10.1/patches/source/python/slack-desc.python-demo
slackware-10.1/source/d/python/slack-desc.python-demo
slackware-9.1/patches/source/python/slack-desc.python-demo
slackware-9.1/source/d/python/slack-desc.python-demo
slackware-current/source/d/python/slack-desc.python-demo

slackware-10.0/patches/source/python/slack-desc.python-tools
slackware-10.0/source/d/python/slack-desc.python-tools
slackware-10.1/patches/source/python/slack-desc.python-tools
slackware-10.1/source/d/python/slack-desc.python-tools
slackware-9.1/patches/source/python/slack-desc.python-tools
slackware-9.1/source/d/python/slack-desc.python-tools
slackware-current/source/d/python/slack-desc.python-tools

> - I assume that at least the first file in each list existed at the time
>   of the transfer (because the first file alphabetically was chosen as
>   the group lead), but it would help to know how many of the files
>   existed beforehand.

Yes & 'all of them', respectively. Scroll down for sequence of pushing hardlinks.

Looking at my backups, I see that these files do in fact exist & have for quite some time (measured in double digit months).

slackware-10.0/source/d/cvs/slack-desc
slackware-10.0/source/d/python/slack-desc
slackware-10.0/source/d/python/slack-desc.python-demo
slackware-10.0/source/d/python/slack-desc.python-tools

> - I also assume that each of these lead files was changed in some way,
>   correct?  I.e. did the first file in each group get mentioned as being
>   updated prior to the errors being output?

In terms of timestamps/permissions/ownership, none of the files were changed. They were simply hardlinked to updated locations. I have no idea as to sequence since I redirect stdout to a file & just noticed stderr stuffs in console.

> - After the transfer, are any of these files present on the destination
>   system (in either the old or new form)?

'Yes' :)

They're hardlinked all over the place from previous updates (2005-apr-05 being the last one).

I'm getting tangled up trying to figure out a clean way to describe this. :(

Push #1 (when errors occurred):

slackware-10.0/patches/source/cvs/slack-desc => slackware-10.0/source/d/cvs/slack-desc

slackware-10.0/patches/source/python/slack-desc => slackware-10.0/source/d/python/slack-desc
slackware-10.0/patches/source/python/slack-desc.python-demo => slackware-10.0/source/d/python/slack-desc.python-demo
slackware-10.0/patches/source/python/slack-desc.python-tools => slackware-10.0/source/d/python/slack-desc.python-tools

slackware-10.0/patches/source/python/slack-desc.python-demo => slackware-10.0/source/d/python/slack-desc.python-demo

slackware-10.0/patches/source/python/slack-desc.python-tools => slackware-10.0/source/d/python/slack-desc.python-tools

Push #2 (to clean up errors):

slackware-10.1/patches/source/cvs/slack-desc => slackware-10.0/patches/source/cvs/slack-desc

slackware-10.1/patches/source/python/slack-desc => slackware-10.0/patches/source/python/slack-desc
slackware-8.1/patches/source/python/slack-desc => slackware-10.0/patches/source/python/slack-desc
slackware-9.0/patches/source/python/slack-desc => slackware-10.0/patches/source/python/slack-desc
slackware-9.1/patches/source/python/slack-desc => slackware-10.0/patches/source/python/slack-desc
slackware-10.1/patches/source/python/slack-desc.python-demo => slackware-10.0/patches/source/python/slack-desc.python-demo
slackware-9.1/patches/source/python/slack-desc.python-demo => slackware-10.0/patches/source/python/slack-desc.python-demo
slackware-10.1/patches/source/python/slack-desc.python-tools => slackware-10.0/patches/source/python/slack-desc.python-tools
slackware-9.1/patches/source/python/slack-desc.python-tools => slackware-10.0/patches/source/python/slack-desc.python-tools

slackware-10.1/patches/source/python/slack-desc.python-demo => slackware-10.0/patches/source/python/slack-desc.python-demo
slackware-9.1/patches/source/python/slack-desc.python-demo => slackware-10.0/patches/source/python/slack-desc.python-demo

slackware-10.1/patches/source/python/slack-desc.python-tools => slackware-10.0/patches/source/python/slack-desc.python-tools
slackware-9.1/patches/source/python/slack-desc.python-tools => slackware-10.0/patches/source/python/slack-desc.python-tools

> - If you re-run the command, do the same errors repeat?

Re-running the rsync push updated the previously errored hardlinks properly. Re: Push #2 noted above.

> I haven't seen any problems in my testing, so I'll need to figure out a
> way to duplicate the failure before I can fix it.

One belated observation. I should have noticed this right off.. <grr>

With the commandline quoted at the beginning of this thread, I've been accustomed to seeing a transfer progress (simplified) as: update files/dirs, update hardlinks, delete files/dirs. Always this order. Period.

Looking at the capture of stdout from last night's session, I noticed a telling difference. Progress was: update files/dirs, update random (single) hardlink, update files/dirs, update small group of hardlinks, update files/dirs, update remaining hardlinks, delete files. No idea where the errors occured in this sequence, I'm afraid. I redirect stdout to a file as a matter of course, but never thought to do the same with stderr.

This last doesn't explain the error itself, but it does jump out at me as being unusual.

Waitaminit! Just had a thought while proofreading this novella. Since the 'update files/dirs' & 'update hardlinks' steps appear to be mixed together instead of completely separate/sequential steps, what about the 'No such file or directory' error actually complaining about the destination _directories_ for the hardlinks being missing (at the time)?

After having taken another look at the stdout capture, it looks suspiciously like this might just be the case.

Ugh, I'm not retyping all this. Call me lazy, but clicking 'send' is ever so much easier to do. :)

Erik