TW
@ovizii please note that this is the issue tracker for attic.
Could you reproduce the integrity error? If so, can you please specify attic version and msgpack version?
@brodul and @bjornfor - please individually state whether you run attic on an ARM cpu - see similar traceback in #309.
@brodul some of attic's tests are already rather close to commandline invocations. Not sure what testing on AWS would give us compared to local and travis CI test runners.
@brodul if your goal is scalability testing, I doubt that travis would be good for that. So if you want to improve tests, maybe rather have a look at coverage....
@jborg I could reproduce the issue seen in https://github.com/jborg/attic/issues/166#issuecomment-68614341 and fixed it like that: https://github.com/ThomasWaldmann/borg/commit/98f3b8d937dea79e86b0c2f9c608a094d01325eb If you could review and provide feedback, that would be great. :)
The repository can be remote (ssh: repo locations) and encrypted. I worked on accelerating cache sync, but it is not easy...
@Schroedingers-Cat symlinking ~/.cache/attic to some directory on a filesystem with more space should work.
@m4nukum4r you have to thank @jborg - attic is his creation. ;) My point with encryption is that a cache somewhere inside the repo directory would have to be encrypted...
I understood what you said in previous post. The current (local) cache is not and does not need to be encrypted. Your local backup source data isn't encrypted either. :)