[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

From: Robert Nichols
Subject: Re: Files in /usr/share/zoneinfo not being backed up
Date: Thu, 29 Dec 2022 10:19:37 -0600
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.5.0

On 12/29/22 2:09 AM, EricZolf wrote:

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
              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.

reply via email to

[Prev in Thread] Current Thread [Next in Thread]