[antoniomika]

This has been replaced with a permissions feature that still provides both delete and overwrite protections. The difference is the underlying store needs to implement it rather than running a server that understands the permission differences. You can read more about this change here: https://github.com/borgbackup/borg/issues/8823#issuecomment-...

[bayindirh]

This comment needs to be pinned, alongside what the developers say [0] since the change is very misunderstood.

> The "no-delete" permission disallows deleting objects as well as overwriting existing objects.

[0]: https://github.com/borgbackup/borg/pull/8798#issuecomment-29...

[zargon]

Isn't this "no-delete permission" just a made-up mode for testing the borg storage layer while simulating a lack of permissions for deleting and overwriting? In actual deployment, whatever backing store is used must have the access control primitives to implement such a restriction. I don't know how to do this on a posix filesystem, for example. Gemini gave me a convoluted solution that requires the client to change permissions after creating the files.

[formerly_proven]

The old append-only mode was a hack that wasn’t very useful in practice anyway, because there were no tools to dissect changes in a repository and the datastructures wouldn’t support that anyway.

Making e.g. snapshots on the backing storage was always the better approach.

[jaegerma]

Thanks for that link. That issue somehow didn't come up when I researched the removal of append-only. The only hint I had was the vague "remove remainders of append-only and quota support" in the change log without any further information.