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

[Robert Nichols]

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.