Issue #988: Why was "new permission handling" was introduced?
Hey Folks, I do not understand all details of the issue #988 "New permissions handling in 1.2.0 causes re-backup of files that haven't changed" [1] and don't ask for that details here. But does someone know why this "new" method of permissions handling was introduced by Germar? What was the intention behind it? Are there known problems with the "old way" before? Greetings Christian [1] -- <https://github.com/bit-team/backintime/issues/988>
Hi, everyone! On 01.11.2022 14:56, c.buhtz@posteo.jp wrote:
I do not understand all details of the issue #988 "New permissions handling in 1.2.0 causes re-backup of files that haven't changed" [1] and don't ask for that details here.
But does someone know why this "new" method of permissions handling was introduced by Germar? What was the intention behind it? Are there known problems with the "old way" before?
Thanks for bringing this up – as I've often said, I think this is one of the most pressing issues. Let me summarize what I've learned from "archaeology" while dealing with https://github.com/bit-team/backintime/blob/master/CHANGES . First, let's recap that backintime is now in the third or fourth Era of its existence. There was: a) the "Dan Era" (first release in 2008 to 1.0.x in 2014, published on a custom blog first, then on Launchpad), b) the "Germar Era" (about 1.1 in 2015 through 1.2 in 2019 migrated from Launchpad to Github in 2015), c) a "Dark Age" of very low maintenance (from 1.2.1 in mid-2019 to 1.3.2 in early 2022), d) and currently the … let's say "Now Era" ;) that started in mid-2022. Let's look at how permissions/copying was handled back then, as far as I know (without researching deeply into the code): 1) First, in the early Dan Era, backintime used `diff` to compare the latest snapshot with the source, in order to check if a new snapshot was necessary. If the answer was yes, it would use `cp` to create a new snapshot. 2a) This was changed in version 0.9.2 in early 2009, when `diff` was replaced by `rsync` for snapshot comparisons – but not for copying the files! That was still done by `cp`. 2b) Shortly afterwards, version 0.9.24 introduced the separate permissions storing file that is fileinfo.bz2 today. CHANGES says: "store basic permission in a special file so it can restore them correctly (even from NTFS)". Before that, I think, files were just `cp`-ied without special permissions handling. 3) In the late Dan Era, version 1.0.22 introduced "full rsync mode". From my understanding, this replaced `cp` with `rsync` for all operations, including full replication of permissions. (Somewhere around this time, the Germar Era started, and he focused on remote backups through ssh. This also required separate permission storage. Remote storage may have been a motivation to eliminate `cp` and rely entirely on `rsync`.) 4) Then, in the late Germar Era in 2019, trouble started with this change in 1.2.0: "make full-rsync mode default, remove the other mode". 4a) The problem is somehow related to the fact that snapshot contain many hardlinks to the same file, but two hardlinks to the same file cannot have different permissions. Somehow, this causes backintime to detect changes when there actually weren't any, and the file is needlessly copied (non-hardlinked!). 4b) Users (including myself) have been having success with the flags "--no-perms --no-group --no-owner" to rsync, which (I guess?!) somehow restores a behavior closer to that of `cp` from 2a) and 2b). Most proposed hotfixes simply restore the previous behavior, effectively reverting the change in 4). So, the main question becomes: How does "full rsync mode" work exactly? Why does it fail to hardlink unchanged files between snapshots in versions since 1.2.0? Is it a good idea to keep it, or revert to `cp`, or do something else? Hope this helps! I'm always happy to discuss this. Cheers, Michael
On Wed, 2022-11-02 at 13:27 +0100, Michael Büker wrote:
Let me summarize what I've learned from "archaeology" while dealing with
https://github.com/bit-team/backintime/blob/master/CHANGES .
First, let's recap that backintime is now in the third or fourth Era of
its existence. There was:
a) the "Dan Era" (first release in 2008 to 1.0.x in 2014, published on a custom blog first, then on Launchpad),
b) the "Germar Era" (about 1.1 in 2015 through 1.2 in 2019 migrated from Launchpad to Github in 2015),
c) a "Dark Age" of very low maintenance (from 1.2.1 in mid-2019 to 1.3.2 in early 2022),
d) and currently the … let's say "Now Era" ;) that started in mid-2022.
Could we add this great summary to a new "History" section in our README? The "era names" could perhaps be "beautified" for this :-)
Moin, Am 04.11.2022 11:53 schrieb BiT dev:
Could we add this great summary to a new "History" section in our README? The "era names" could perhaps be "beautified" for this :-)
Very good idea esspecialy to value the work and invest of the past contributors. But I vote for an extra HISTORY.md file and link it in README.md. I also would vote for an extra CONTRIBUTE.md (linked in README.md) which explains all the git, make, build dependencies and nerdy things you need to know when you want to work directly with the repo. HISTORY and CONTRIBUTE should IMHO go in the root folder of the repo beside README.
Moin!
Am 04.11.2022 11:53 schrieb BiT dev:
Could we add this great summary to a new "History" section in our README? The "era names" could perhaps be "beautified" for this :-)
Very good idea esspecialy to value the work and invest of the past contributors. But I vote for an extra HISTORY.md file and link it in README.md.
I also would vote for an extra CONTRIBUTE.md (linked in README.md) which explains all the git, make, build dependencies and nerdy things you need to know when you want to work directly with the repo.
HISTORY and CONTRIBUTE should IMHO go in the root folder of the repo beside README.
I agree! I'll make a mental note to write a HISTORY.md someday™ :) Cheers, Michael
On Fri, 2022-11-04 at 14:16 +0100, Michael Büker wrote:
HISTORY and CONTRIBUTE should IMHO go in the root folder of the repo beside README.
I agree! I'll make a mental note to write a HISTORY.md someday™ :)
History meets future - I hope we do not cause a time paradoxon ;-)))
participants (3)
-
BiT dev
-
c.buhtz@posteo.jp
-
Michael Büker