[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: EricZolf
Subject: Re: Files in /usr/share/zoneinfo not being backed up
Date: Thu, 29 Dec 2022 09:09:54 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.6.0


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.

KR, Eric

reply via email to

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