Re: Files in /usr/share/zoneinfo not being backed up

On 12/29/22 2:09 AM, EricZolf wrote:
> Hi,
> 
> On 28/12/2022 10:57, EricZolf wrote:
>> On 28/12/2022 03:25, Robert Nichols wrote:
>>> Running version 2.2.0 (both client and server), a backup since a recent zoneinfo update results in hundreds of warnings of the form:
>>>      WARNING: Attempt to rename over same inode: from path
>>> /media/sysbk/lenovo-F36/usr/share/zoneinfo/right/US/rdiff-backup.tmp.36105
>>>               to path /media/sysbk/lenovo-F36/usr/share/zoneinfo/right/US/Hawaii
>>>
>>> and none of the files under /usr/share/zoneinfo get updated in the archive. Reverting the server to rdiff-backup 2.0.5 eliminates the problem.
>>>
>>> Anyone else seeing this?  I have not yet had a chance to check this with the intermediate release candidate versions.
>>>
>> I haven't seen the issue but I have changed things in temporary files and hardlinked files (I guess this is were this is coming from).
>> Can you check the relationship in inodes between those files and create an issue for this?
> 
> Out of curiosity, I tried the following but it didn't trigger any issue, so something "stranger" happened with the zone files (which are hard-linked all over the place indeed):
> 
> 
> mkdir from
> date > from/fileA
> ln from/fileA from/fileB
> rdiff-backup -v5 backup from to
> date > from/fileA
> rdiff-backup -v5 backup from to
> 
> 
> Are you using Fedora 36 as in F36? So do I, even if I'm already at F37 and didn't get the issue.
> `sudo dnf history tzdata` followed by `sudo dnf history info 1234 | grep tzdata` (1234 being the ID of the suspected dnf transaction) should help identify which upgrade was done causing the issue. I got on the 18th of December tzdata-2022f-1.fc37.noarch upgraded to tzdata-2022g-1.fc37.noarch.

Yes, that laptop is running Fedora 36, and my history with tzdata is the same as yours except the update was done 17 December 2022.

I am working on setting up an environment with a snapshot of the rdiff-backup archive as it was at the time of the error. A brief sampling shows the hardlink groups were the same before and after the tzdata update, though of course the actual inode numbers all changed. After each rdiff-backup session, I do run an audit to confirm that the hardlink arrangement in the mirror agrees with the mirror_metadata file (Again, the inode numbers in the mirror are not the same as the source inode numbers in the mirror_metadata file, but the groupings need to be the same.), so there's no issue there.

-- 
Bob Nichols     "NOSPAM" is really part of my email address.
                 Do NOT delete it.