TW

From borg 1.4.2 change log: create: add --files-changed=MODE option (controls how borg detects whether a file has changed while it is being backed up) So, guess that solves this.

Some breakage with the stats is expected due to the new `AdHocWithFilesCache` cache implementation. The old `LocalCache` implementation did precise refcounting and also had the chunk size in the `chunks`...

So, yes, that is kind of a bug, but the solution might be not fixing it, but doing it differently.

Guess beta 10 will be also quite a bit "off" concerning stats at misc. places, because I ripped out a lot of code that was mostly "in the way". Good...

7a93890602cb3b1434f46076d83299a57de8a643 removed the "deduplicated size" computation completely, also the "Deduplicated size:" from `borg info` output was removed. It was not that useful anyway and hard to understand (and often misunderstood).

Interesting idea for making scripting a bit easier. I have to check whether a `borg compact --dry-run` can be doing anything useful (like e.g. saying how much it would compact/free)...

@level323 the files index does not need to be shared. it just remembers the mtime/size/inode/chunks info for all files of last backup, so it can quickly skip the files next...

@RonnyPfannschmidt well, a segment has 5MB, so a 500GB repo has 100.000 segments. That's just an example, but a quite realistic one. Of course, it can be more or less...

@callegar I currently have no near-future plans to implement this. Priority now is on getting 1.2 out (b4 released, rc1 next), then fixing any potential issues with that. After that:...

If you'ld rather not want to have that cache, see the FAQ about how to get rid of it (search chunks.archives.d). It is not required, but can speed up re-syncing...