LinboImage.rename() deletes the image's .torrent and never creates the replacement, so a renamed image is left without a torrent.
Where
usr/lib/python3/dist-packages/linuxmusterTools/linbo/images.py, in rename() (lines 247-251 on master today):
# Need to generate a new torrent file
if extra == "torrent":
os.unlink(actual)
continueThe comment states the intent, but nothing creates the new torrent. linbo-torrent is invoked exactly once in the whole file, and only to stop:
subprocess.check_output(['/usr/sbin/linbo-torrent', 'stop', os.path.join(self.path, f'{self.image}.torrent')])Deleting rather than renaming is right in itself, since a torrent embeds the file name it describes. What is missing is the follow-up create.
Effect
After a rename through the API the image directory holds .qcow2, .desc, .info, .macct, .hash and .reg under the new name, and no .torrent at all. Groups configured with DownloadType = torrent have no torrent for that image any more. Renaming the image back does not bring it back, because the file is gone rather than orphaned under the old name.
Reproduce
- Take an image that has a
.torrent next to it.
- Rename it through the API (
POST /v1/linbo/images/{name}/rename).
ls /srv/linbo/images/<new name>/ — every other sidecar is renamed, the torrent is absent.
Observed on Tools 7.4.14, LINBO 7.4.12, API 7.4.11.
Suggested fix
/usr/sbin/linbo-torrent already has the verb:
linbo-torrent create <image_file>
Its create() rebuilds the torrent, saves the hash and starts seeding. A _torrent_create() helper mirroring the existing _torrent_stop(), called after the rename completes, restores the previous state.
LinboImage.rename()deletes the image's.torrentand never creates the replacement, so a renamed image is left without a torrent.Where
usr/lib/python3/dist-packages/linuxmusterTools/linbo/images.py, inrename()(lines 247-251 on master today):The comment states the intent, but nothing creates the new torrent.
linbo-torrentis invoked exactly once in the whole file, and only to stop:Deleting rather than renaming is right in itself, since a torrent embeds the file name it describes. What is missing is the follow-up
create.Effect
After a rename through the API the image directory holds
.qcow2,.desc,.info,.macct,.hashand.regunder the new name, and no.torrentat all. Groups configured withDownloadType = torrenthave no torrent for that image any more. Renaming the image back does not bring it back, because the file is gone rather than orphaned under the old name.Reproduce
.torrentnext to it.POST /v1/linbo/images/{name}/rename).ls /srv/linbo/images/<new name>/— every other sidecar is renamed, the torrent is absent.Observed on Tools 7.4.14, LINBO 7.4.12, API 7.4.11.
Suggested fix
/usr/sbin/linbo-torrentalready has the verb:Its
create()rebuilds the torrent, saves the hash and starts seeding. A_torrent_create()helper mirroring the existing_torrent_stop(), called after the rename completes, restores the previous state.