Re: Files in /usr/share/zoneinfo not being backed up
EricZolf <[email protected]>
| Newsgroups | gmane.comp.sysutils.backup.rdiff-backup.general |
|---|---|
| Organization | rdiff-backup.net |
| Message-ID | <[email protected]> |
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. KR, Eric