borg 1.x: add length limit to archivename_validator?

[ThomasWaldmann]

archivename_validator: master branch has a length limit there, but 1.4-maint branch doesn't.

maybe it would be good to also have the limit in borg 1.x, to avoid issues when migrating to borg2.

even though the validator has no limit yet in borg 1.x, guess that didn't mean arbitrarily long archive names "just worked".

E.g. when mounting a borg repo, the archive names are used as directory names and on Linux NAME_MAX is 255, so a directory name can't be longer than that.

Update: I noticed that this is a bit more than just the length limit of archive names. IIRC comments length might also be different and also accepted content for names / comments. One has to check the metadata validators borg2 uses currently.

[ThomasWaldmann]

borg 1.x creates checkpoint archives named <archive name>.checkpoint<number> so the validator needs to allow these names also (and somehow deal with their longer name length).

checkpoint archives won't be migrated to borg2 (no need to do that, we just migrate the final/full archive, not the incomplete checkpoint archive).

[SpiritInAShell]

checkpoint archives won't be migrated to borg2 (no need to do that, we just migrate the final/full archive, not the incomplete checkpoint archive).

This is not stated in the documentation for borg 2 beta 14 ( https://borgbackup.readthedocs.io/en/2.0.0b14/usage/transfer.html ), but should be because of weird edge cases like:

"Just migrate final/full archive" covers one case, but there can be checkpoint archives that never completed, so archive1.checkpoint but no archive1.

Why no final archive?

• I ran a backup on a disk that never finished. The disk died. The checkpoint archive is the only data remaining. I believe I renamed the archive to archive1_incomplete so nothing will be lost when .checkpoint is not transfered.
• with borg1 running backups on Android devices (unplanned/whenever user desires) over public Wifis with common connection losses (shorter checkpoint interval set). Every run creates an archive with date/time stamp. Remaining .checkpoint archives currently are not touched. Yes, this might not be a very common use case. I understand, that borg2 will overcome that by design (no timestamps in name required, also no archives for unfinished backups)

[SpiritInAShell]

archivename_validator: master branch has a length limit there, but 1.4-maint branch doesn't.

...

even though the validator has no limit yet in borg 1.x, guess that didn't mean arbitrarily long archive names "just worked".

I have borg1 repos with a few archive names that extend to over 200chars ( #8322 ). Those need to be handled, when...

• addressing those existing archives by name within borg1.4.1+ (mount/recreate/extract/list/... must accept names longer than the new limit)
• when transferring from borg1 to borg2

For the latter: maybe preserving the full archive name in --comment field, replacing (prepending/appending) it with unique identifiers to make it accessible/identifiable.

otherwise, stripping parts from an archive name may create many archives with the identical string, like:

use case: my borg1 archives end mostly with the time stamp (_YYYY-MM-DD_HH-MM-SS), so if transfer happened to remove eg. the last 20 chars from the archive name, it may create many identical archive names.

(For the sake of simplicity: renaming/shortening archive names prior borg2 transfer would be totally fine with me.)

[ThomasWaldmann]

I don't want to make transfer more complex than it already is (like by adding archive renaming).

The (likely few) users with exceedingly long archive names will have to shorten them (e.g. by using borg rename) before transferring to borg2 (in any case, and if we add the limit to borg 1.x, then also before upgrading to these versions).

I also don't like dirty hacks like abusing the comment field for other metadata.

About the .checkpoint archives: this is rarely a problem, but we can't completely rule it out:

• prune removes .checkpoint archives except if there is no more recent archive. if one has "valuable" checkpoint archives, one better renames before that happens (as you did).
• usually users create backups regularly, so even if there is archive_20250101.checkpoint (incomplete) and no archive_20250101 (complete), there likely is a more useful archive_20250102, ...

It has to be documented that borg transfer does not transfer checkpoint archives and will reject archives that do not pass metadata validation (e.g. due to issues in names or comments, see the validator code). Please make a separate PR for this.

The fix for THIS issue will need some changelog entry / upgrade notes entry and maybe there should be a version bump to e.g. borg 1.5 to indicate that there might be a bit more to do than in just a 1.4.x patch release. The main idea about doing that in 1.x at all is that users are better prepared for borg2 and do not continue to create archives that would make troubles when transferring them to borg2.