🇬🇧 English · 🇫🇷 Français

S'applique à Hydranos 4.4.

Cette page s'adresse à vous si vous agissez sur beaucoup de torrents à la fois, si vous déplacez des données entre dossiers ou disques, ou si vous supprimez des torrents. Vous y verrez ce que fait réellement chaque entrée du menu contextuel, comment un déplacement de données s'exécute et échoue, ce qu'affiche l'onglet Jobs, et quels fichiers exactement une suppression efface.

Deux mots ont ici un sens strict. Une tâche groupée (bulk task) est ce que lance une action du menu contextuel : elle vit en mémoire et dispose d'un panneau de progression. Un job (tâche de fond) est un déplacement persistant en arrière-plan (move_data, graduate, ou handoff pour un déplacement vers un autre nœud), listé dans l'onglet Jobs. Les autres termes (store, état de reprise, mode seed) sont définis sur Concepts & glossaire.

Sélectionnez des lignes dans la liste Race ou Hoard, puis faites un clic droit. Un clic sélectionne une ligne, Ctrl/Cmd-clic en ajoute ou retire une, Maj-clic sélectionne une plage. Ctrl+A sur le tableau Hoard sélectionne tous les torrents qui correspondent au filtre en cours, pas seulement les 500 lignes affichées. Ctrl+A ne fait rien sur le tableau Race.

Chaque entrée du menu, sauf le groupe Exporter (Export), envoie la sélection à POST /api/selection/<action> et lance une tâche groupée (l'export télécharge un fichier, voir Exporter). La sélection voyage sous l'une de deux formes :

• Par lignes : les hash que vous avez choisis, chacun avec sa copie (local-hoard, local-race, ou <node>-<engine> pour une ligne distante).
• Par filtre (Ctrl+A) : le filtre de la liste lui-même, plus expect, le nombre qui vous a été affiché. Si le filtre correspond maintenant à plus de torrents que expect, le serveur refuse avec un 409 grew et l'interface demande Le filtre correspond maintenant à {n} torrents, pas {m}. Appliquer aux {n} ? (The filter now matches {n} torrents, not {m}. Apply to all {n}?). Moins est accepté. Une sélection vide est toujours refusée ; elle ne signifie jamais « tout ».

Au-delà de 500 torrents, Arrêter (Stop), Démarrer (Start) et les deux entrées de suppression demandent d'abord une confirmation. Annuler (Cancel) dans le panneau de progression s'arrête entre deux torrents pour les actions torrent par torrent, entre deux lots de 10 000 torrents pour Arrêter, Démarrer, Forcer le téléchargement (Force download), Modifier les tags (Edit tags), Limites de partage… (Share limits…) et Changer de catégorie › (Change category ›) (modifications du store seul), et entre deux séries de 8 pour Re-annoncer (Reannounce). Le panneau et ses lignes de résultat sont décrits sur Visite de l'interface web. Une tâche groupée est perdue au redémarrage et n'apparaît jamais dans l'onglet Jobs.

Les lignes « ignorées » sont comptées comme {n} non concernés ({n} not applicable) dans le panneau de progression. Chaque entrée propre à une copie agit sur la copie qu'est la ligne : la ligne d'un moteur supplémentaire (local-<id>) envoie ?engine=<id> (ou ?agent=local-<id>). Re-annoncer et Duplicate to engine › sont les exceptions : Re-annoncer annonce la première copie trouvée (ci-dessous), Duplicate pointe le nouveau moteur sur le chemin de sauvegarde de la première copie. Les lignes qui viennent d'un autre nœud sont relayées à ce nœud (Arrêter/Démarrer, Re-annoncer, Vérifier à nouveau, les deux entrées Changer de catégorie, Déplacer vers un dossier…, Limiter le débit…, ordre de téléchargement, suppression) ; Modifier les tags ›, Forcer le téléchargement et Limites de partage… sont comptés {n} absents de ce nœud ({n} not on this node). Sur les lignes distantes, les entrées de moteur ne proposent que local-<id> (bring it here, un rapatriement) et, sous Move to engine ›, les autres moteurs du nœud qui détient la ligne (there, no copy). Voir Nœuds & plusieurs machines.

Bug connu en 4.4 : un Re-annoncer groupé semble agir sur la copie qu'est la ligne, comme Arrêter, Vérifier à nouveau ou Limiter le débit… — il ne nomme aucun moteur, donc pour un hash détenu par deux moteurs il annonce la première copie trouvée, qui peut être l'autre. Constaté à la lecture du code, non reproduit — pour annoncer une seule copie, appelez POST /api/torrents/<hash>/reannounce?engine=<id>.

Vérifier à nouveau et Modifier les tags › sont masqués quand la sélection ne contient aucune ligne hoard, et Ctrl+A n'existe pas sur le tableau Race : depuis le seul onglet Race, le menu n'offre aucune revérification groupée. Passez par l'API (POST /api/selection/recheck, ci-dessous), qui revérifie aussi les copies race.

# Stop every torrent of category "tv" in the hoard list (expect = the count you saw)
curl -X POST http://localhost:8199/api/selection/stop \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"selection":{"filter":"category=tv","view":"hoard","expect":120},"params":{}}'
# -> 202 {"job":"sel…","total":120}

curl -H "X-Api-Key: YOUR_API_KEY" http://localhost:8199/api/selection/jobs/sel0123456789ab

Clés de filtre : search, category, category_not, tag, tag_not, tracker, tracker_not, error_class, error_class_not, state. Chaque corps de requête rejette les champs inconnus avec un 400 qui les nomme. La liste complète des actions est sur API REST.

Six choses lancent un déplacement de données dans Hydranos :

• Déplacer vers un dossier… : n'importe quel dossier absolu, catégorie inchangée.
• Changer de catégorie + déplacer les fichiers › : le Chemin d'enregistrement (Save Path) de la catégorie. L'arbre de décision (changement d'étiquette, déplacement, ou graduation vers l'autre moteur) est dessiné sur Catégories & routage.
• Une action de workflow move files to a folder (set_location) : mêmes vérifications que Déplacer vers un dossier… (voir Workflows).
• L'outil MCP move_to_category, qui envoie la même requête que Changer de catégorie + déplacer les fichiers › (voir Serveur MCP).
• POST /api/torrents/:hash/graduate {"engine":"hoard","category":"tv"} (ou un save_path ; sans lui, le Chemin d'enregistrement de la catégorie est utilisé, sinon 400 save_path is required (or a category that has one)). Elle effectue les mêmes vérifications qu'un déplacement par catégorie ci-dessous, accepte "allow_breaking_hardlinks": true, et répond 200 {"status":"queued","job":…,"plan":…}.
• Le drain race, qui met en file des jobs graduate sans ces vérifications (voir Drain race & graduation).

Un déplacement vers un autre nœud n'est pas un déplacement de données sur cette machine : c'est un job handoff qui attend le nœud (voir L'onglet Jobs).

L'invite indique Chemin absolu du dossier où déplacer les données. La catégorie ne change pas. Un torrent à plusieurs fichiers garde son propre dossier à l'intérieur de celui-ci. (Absolute path of the folder to move the data to. The category does not change. A torrent with several files keeps its own folder inside this one.) Avec une seule ligne sélectionnée, elle est préremplie avec le chemin de sauvegarde actuel.

• Le chemin doit être absolu et .. est refusé (400) ; un . dans le chemin est supprimé sans avertissement (/data/./tv devient /data/tv). Un séparateur final est supprimé. L'API ne retire pas les espaces (un nom de dossier peut se terminer par un espace) ; l'interface retire ceux que vous tapez. Les chemins avec lecteur (D:\media) ne sont acceptés que sur la version Windows ; sous Linux ils sont refusés comme non absolus.
• Un torrent multi-fichiers arrive dans <target>/<torrent name>/… ; un torrent à fichier unique arrive directement dans <target>.
• Seuls les fichiers du torrent lui-même bougent, fichier par fichier. Les autres fichiers du même dossier restent. Les fichiers absents à la source sont ignorés.
• Si le dossier cible est le chemin de sauvegarde actuel du torrent (une comparaison de chemins, pas un examen des fichiers), rien n'est mis en file : 200 {"status":"ok","moved":false}.

curl -X POST http://localhost:8199/api/hoard/torrents/0123456789abcdef0123456789abcdef01234567/location \
  -H "X-Api-Key: YOUR_API_KEY" -H "Content-Type: application/json" \
  -d '{"location":"/data/archive"}'
# -> 202 {"status":"moving","job":"job…","kind":"move_data","plan":{…}}

Utilisez /api/race/… pour une copie race, et ?engine=vpn1 pour une copie dans un moteur supplémentaire.

flowchart TD
    A["Set location, Change category + move files,<br/>workflow set_location"] --> K{"Changement vers une catégorie<br/>de l'autre mode ?"}
    K -->|"non, ou Set location"| N{"Dossier cible = chemin<br/>de sauvegarde actuel ?"}
    N -->|"oui"| N2["200, moved false<br/>rien en file"]
    N -->|"non"| B
    K -->|"oui, même si le chemin<br/>de sauvegarde ne change pas"| B{"unsafe_path, shared<br/>ou destination_taken ?"}
    G["POST /api/torrents/HASH/graduate"] --> B
    B -->|"oui"| X["409, refusé<br/>quelle que soit votre réponse"]
    B -->|"non"| C{"Des fichiers en hardlink doivent être copiés<br/>sans consentement donné ?"}
    C -->|"oui"| H["409 hardlinks<br/>l'interface demande : Les déplacer quand même ?"]
    H -->|"oui : renvoyé avec allow_breaking_hardlinks"| A
    C -->|"non"| D{"Assez d'espace libre<br/>à la cible ?"}
    D -->|"non"| S["409 space"]
    D -->|"oui"| Q{"Un déplacement déjà en file<br/>ou en cours pour ce torrent ?"}
    Q -->|"oui"| Q2["409 déjà en file"]
    Q -->|"non, même mode"| MD["202 : job move_data<br/>même moteur, vérifications refaites,<br/>retour arrière en cas d'échec"]
    Q -->|"non, autre mode, ou /graduate"| GR["job graduate en file<br/>202, ou 200 depuis /graduate"]
    DR["Drain race"] -->|"aucune vérification de chemin, partage, destination,<br/>hardlink ou espace ;<br/>ignoré si un déplacement est déjà en file"| GJ
    GR --> GJ["le job graduate s'exécute :<br/>retiré de la source d'abord,<br/>retour arrière en cas d'échec ou d'annulation"]

Pour Changer de catégorie + déplacer les fichiers ›, le test de mode passe en premier : une catégorie de l'autre mode met toujours en file un graduate, même quand son chemin de sauvegarde est celui où se trouvent déjà les données.

Chaque 409, sauf « déjà en file », contient un objet plan : from, to, files, bytes, missing_files, rename_files, copy_files, copy_bytes, hardlinked_files, hardlinked_bytes, free_bytes, enough_space, unsafe_path, shared_with, occupied (les fichiers déjà présents à la destination), et un reason qui nomme la ligne du tableau ci-dessus. « Le même fichier » signifie le même inode sous Linux (un hardlink de ce fichier convient) et le même chemin canonique sous Windows.

Un job move_data refait ces vérifications (unsafe_path, shared, destination_taken, hardlinks, espace) quand son tour vient, et échoue avec …; nothing was moved si l'une d'elles ne passe plus. Un job graduate ne les refait pas : il refuse seulement, fichier par fichier, un fichier en hardlink à copier sans consentement ou un fichier plus gros que l'espace libre, et revient en arrière.

Simulation. GET /api/{race,hoard}/torrents/:hash/move-preview?category=tv renvoie kind (relabel, move_data ou graduate), engine, target_engine et, pour move_data et graduate, le même plan (une réponse relabel n'en a pas), sans rien déplacer. category est obligatoire (400 sans). Elle ne prévisualise qu'un déplacement par catégorie ; il n'existe pas d'aperçu pour un emplacement libre.

Un job est une ligne de la table jobs du store. Il survit aux redémarrages. Deux types déplacent des données sur cette machine :

Un troisième type, handoff, ne déplace rien ici : c'est un déplacement vers un autre nœud qui attend que ce nœud détienne une copie complète (voir L'onglet Jobs).

Règles communes :

• Un seul job à la fois pour toute l'instance, le plus ancien d'abord. L'exécuteur cherche du travail toutes les 5 s. Un job handoff n'occupe pas cette place.
• Les copies sont une simple boucle lecture/écriture avec des tampons de 4 MiB et un fsync par fichier. Elle évite volontairement copy_file_range, pour que ZFS ne fasse jamais de block-cloning des données. Il n'y a pas de limite de débit, ni de clé de configuration pour en fixer une.
• « Même système de fichiers » signifie même identifiant de périphérique sous Linux et même numéro de série de volume sous Windows.
• Après un redémarrage, les jobs qui étaient running ou cancelling repassent en queued avec une progression remise à zéro, et sont relancés depuis le début. Ils ne reprennent pas là où ils s'étaient arrêtés, et une annulation inachevée est oubliée : annulez de nouveau le job. Les jobs waiting (handoff) continuent d'attendre.
• La progression compte les octets des fichiers copiés ou renommés.

sequenceDiagram
    participant U as Vous
    participant A as API Hydranos
    participant R as Exécuteur de jobs
    participant E as Moteur
    participant D as Disque
    participant S as Store
    U->>A: POST .../location ou .../category avec move_files
    A->>A: vérifications (chemin dangereux, partage, destination occupée, hardlinks, espace, déjà en file)
    A-->>U: 202 + id du job
    Note over R: un seul job à la fois
    R->>R: nouveau plan et nouvelle vérification du partage, de la destination occupée, des hardlinks, de l'espace libre
    R->>D: copie des fichiers dont la cible est sur un autre système de fichiers
    Note over E,D: le torrent continue de seeder depuis les originaux
    alt une copie échoue
        R->>D: suppression des copies déjà faites
        R->>S: job en échec, rien n'a bougé
    else copies terminées
        R->>E: capture de l'enregistrement de reprise, retrait du torrent, données conservées
        R->>D: renommage des fichiers sur le même système de fichiers
        R->>E: réimport de l'enregistrement au nouveau dossier
        alt le renommage ou le réimport échoue
            R->>D: annulation des renommages, suppression des copies
            R->>E: réimport de l'enregistrement à l'ancien dossier
            R->>S: job en échec, retour arrière effectué
        else réimporté
            R->>S: chemin de sauvegarde (et catégorie) mis à jour
            R->>D: suppression des originaux copiés, nettoyage des sous-dossiers vidés
            R->>S: job terminé
        end
    end

Il n'y a pas d'étape de vérification par hash : la copie est considérée comme fiable. Les sous-dossiers vidés sous l'ancien chemin de sauvegarde sont supprimés, jamais l'ancien chemin de sauvegarde lui-même (d'autres torrents peuvent le partager). Si un original ne peut pas être supprimé à la fin, le job réussit quand même et le journal affiche un avertissement.

1. Capture l'enregistrement de reprise du torrent (pièces détenues, trackers modifiés, compteurs d'octets, temps de seed, état d'arrêt, ses propres plafonds de débit et son ordre de téléchargement), puis le retire du moteur source, en conservant ses données.
2. Déplace chaque fichier : renommage sur le même système de fichiers ; sinon vérifie l'espace libre et les hardlinks pour ce fichier, le copie, puis supprime le fichier source. Une Annulation est prise en compte entre deux fichiers.
3. Le moteur cible adopte le torrent au nouveau dossier à partir de cet enregistrement, comme le relit un redémarrage : pas de revérification, rien de remis à zéro, un torrent arrêté reste arrêté.
4. Met à jour le store : moteur, chemin de sauvegarde, catégorie.

Tout échec après l'étape 1 (un fichier en hardlink sans consentement, un disque plein, une cible qui refuse le torrent) et toute Annulation sont défaits : les fichiers déjà déplacés sont remis en place, le moteur source adopte de nouveau l'enregistrement, et le job se termine avec la raison suivie de l'une de ces fins :

Une graduation annulée se termine en Annulé (Cancelled), une graduation en échec en Échec.

Une graduation planifie d'abord ses fichiers comme un déplacement : si un fichier du même nom se trouve déjà à la destination (en général celui d'un autre torrent), le job est refusé (… already exist …; nothing was moved) et le torrent reste où il est. Le drain race vérifie la même chose avant de mettre une graduation en file, et journalise par catégorie les torrents qu'il laisse en place pour cette raison, en WARN not graduated: files of the same name already sit at the destination….

Chaque déplacement transporte le torrent tel qu'il était. Une graduation et Move to engine › passent son enregistrement de reprise au moteur cible ; un job move_data (Déplacer vers un dossier…, un Changer de catégorie + déplacer les fichiers › du même mode, workflow set_location) réimporte l'enregistrement propre au torrent au nouveau dossier. Les pièces détenues, les trackers modifiés, les compteurs d'octets (donc le ratio), le temps de seed, l'état d'arrêt, ses propres plafonds de débit et son ordre de téléchargement sont conservés, avec la catégorie, les tags et les limites de partage ; rien n'est revérifié, et un torrent inachevé continue de se télécharger au nouvel endroit.

Duplicate to engine › ajoute une seconde copie en mode seed, sur les mêmes fichiers. Il est refusé (409 … does not hold all of it yet; duplicate it once it is complete) tant que la source n'est pas complète ou est en cours de vérification.

Le crédit chez votre tracker, pour tous les types de déplacement : le moteur source lâche le torrent sans annoncer stopped (une suppression, elle, l'annonce), donc l'envoi effectué depuis sa dernière annonce n'est jamais déclaré. Le torrent déplacé démarre ensuite une nouvelle session d'annonce à partir de 0, comme après un redémarrage (voir Trackers & annonces). L'envoi déjà annoncé est crédité par le tracker et reste acquis.

L'onglet Jobs indique Travaux de longue haleine : le déplacement des données d'un torrent entre systèmes de fichiers continue ici, et le torrent continue de partager pendant ce temps. (Long-running work: moving a torrent's data between filesystems keeps running here, and the torrent keeps seeding while it does.) Cette phrase n'est vraie que pour move_data : un job graduate cesse de seeder pendant la copie, et un job handoff ne copie rien ici. Il liste les 200 jobs les plus récents, rafraîchis toutes les 2 s tant que l'onglet est ouvert, plus un bouton Rafraîchir (Refresh). Actifs seulement (Active only) garde les jobs pas encore terminés (queued, running, cancelling, waiting).

Sans aucune ligne, le tableau affiche Rien en cours. (Nothing running.) Les jobs terminés restent dans la liste.

Annuler demande Annuler ce job ? Un job en attente est abandonné. Un déplacement vers un autre engine s'arrête après le fichier en cours et tout est remis comme avant ; un autre déplacement en cours ne peut pas être interrompu et se termine. Un déplacement vers un node cesse d'attendre : les deux copies sont gardées. (Cancel this job? A waiting job is dropped. A move to another engine stops after the current file and is put back as it was; another running move cannot be interrupted and finishes. A move to a node stops waiting: both copies are kept.) Ce que fait le serveur :

Move to engine › avec une cible de type nœud (<node>-<engine>) envoie le torrent au nœud, puis met en file un job handoff à l'état waiting (la tâche groupée le compte {n} envoyé(s) ; la copie locale part quand le node l'a en entier (Jobs) ({n} sent; the local copy goes once the node holds it (Jobs))). Toutes les 30 s, le job demande au nœud ce qu'il détient. À 100 %, il retire chaque copie locale avec ses fichiers (sauf les fichiers que lit un torrent d'un autre hash). Si le nœud est retiré, ou ne déclare pas de copie complète dans les 6 heures (l'échéance est enregistrée dans le job, donc un redémarrage la conserve), le job échoue et la copie locale est conservée. Un second déplacement du même torrent pendant qu'un premier attend est refusé (409 a move of this torrent to a node is already waiting; see Jobs). Duplicate to engine › vers un nœud ne crée aucun job. Détails : Nœuds & plusieurs machines.

API : GET /api/jobs?limit= (100 par défaut, les plus récents d'abord) et GET /api/jobs/:id, chaque job avec id, type, state (queued, running, cancelling, waiting, done, failed, cancelled), info_hash, params, progress_bytes, total_bytes, percent, error, created_at, updated_at. DELETE /api/jobs/:id est Annuler, avec les réponses ci-dessus. POST /api/jobs/move-remote a disparu : toute requête reçoit un 410 qui renvoie vers POST /api/selection/handoff (voir Mettre à jour depuis la 3.x).

Un même torrent peut être détenu par plusieurs moteurs de la même instance. Chaque copie a sa propre catégorie, son propre état d'arrêt et son propre peer id, et les copies partagent les mêmes fichiers.

• Deux copies sur les mêmes fichiers sont désormais liées : Déplacer vers un dossier… ou un déplacement par catégorie de l'une ou l'autre est refusé avec shared (le déplacement laisserait l'autre sans rien à servir), et Retirer + supprimer les fichiers sur l'une conserve les fichiers que lit l'autre (voir Supprimer).
• Sur la plupart des routes propres à une copie, ?engine=<id> désigne la copie visée (?agent=local-<id> est l'ancienne écriture de la même chose). /graduate et /copy l'ignorent et utilisent la première copie trouvée.
• Les cibles de type nœud (<node>-<engine>) sont un handoff via BitTorrent : Move to engine › vers un nœud est un job handoff (voir Déplacements vers un nœud), Duplicate to engine › vers un nœud n'est pas un job. Voir Nœuds & plusieurs machines.

Le groupe de menu Node qui contient ces deux entrées s'affiche dès que cette instance a deux moteurs (toujours, avec race et hoard par défaut) ou qu'un nœud est déclaré. Plus d'informations sur les moteurs supplémentaires : Moteurs : race & hoard.

Le groupe Exporter télécharge la sélection (Ctrl+A compris) sous forme d'un seul fichier envoyé en flux :

Pour le zip, une boîte de dialogue avertit que le .torrent d'un tracker privé contient votre passkey dans son URL d'annonce (a private tracker's .torrent carries your passkey in its announce URL) et propose Garder les trackers (Keep trackers) ou Retirer les trackers (Remove trackers). Retirer les trackers supprime uniquement announce et announce-list ; l'info hash ne change pas. Un fichier qui ne peut pas être réécrit est écarté et listé dans missing.txt plutôt qu'exporté avec sa passkey. Le .torrent exporté est celui stocké au moment de l'ajout : les modifications de trackers faites dans Hydranos n'y figurent pas.

curl -X POST "http://localhost:8199/api/torrents/export" -H "X-Api-Key: YOUR_API_KEY" \
  -d format=zip -d strip_trackers=1 \
  -d hashes=0123456789abcdef0123456789abcdef01234567 -o export.zip

Le formulaire accepte selection (le même JSON que pour une action groupée) ou hashes (séparés par des virgules), et format=zip|txt|csv.

Retirer le torrent conserve les fichiers ; Retirer + supprimer les fichiers les supprime. Depuis le menu contextuel, chacune retire uniquement la copie sélectionnée. La route REST DELETE /api/torrents/:hash?delete_files=true sans engine retire toutes les copies, tout comme torrents/delete du shim qBittorrent.

Ce qui est supprimé sur le disque :

• Fichier par fichier, uniquement les fichiers que le torrent nomme. Jamais de suppression récursive de dossier. Les sous-dossiers vidés d'un torrent multi-fichiers sont supprimés de bas en haut ; un dossier qui contient encore un fichier étranger reste.
• Les fichiers qu'un autre torrent chargé lit exactement au même chemin sont conservés, dans n'importe quel moteur : un cross-seed, un upload seedé depuis ses fichiers sources, ou la copie de ce même torrent dans un autre moteur pointée sur le même dossier (Duplicate to engine ›). Le journal indique files kept: another torrent reads them. La comparaison porte sur les chemins, pas sur les inodes : un hardlink dans votre médiathèque est un autre nom et conserve de toute façon ses octets.
• Une copie qui a ses propres données ne protège rien. Si la copie race et la copie hoard d'un même torrent sont dans deux dossiers différents (la même release récupérée deux fois), en retirer une avec + supprimer les fichiers (+ delete files) supprime les fichiers de son dossier, quoi que détienne l'autre copie.
• Retirer toutes les copies d'un coup (DELETE sans engine) supprime les fichiers propres à chaque copie, moins ce que lit un torrent d'un autre hash ; deux copies sur le même chemin perdent ce chemin quand la dernière d'entre elles part.
• Un fichier absent n'est pas une erreur.

Pour deux torrents au contenu différent sous les mêmes noms de fichiers, voir Fichiers qu'un autre torrent détient déjà : depuis la 4.4, un ajout ne les laisse plus partager un chemin (sauf avec [dedup] path_collision = "legacy").

Le moteur envoie stopped aux trackers, retire le torrent, puis reporte ses octets cumulés dans les compteurs globaux de l'instance et supprime la ligne du store. L'état de reprise du moteur pour ce torrent est effacé. POST /api/race/torrents/:hash/purge retire la copie race de la même façon, avec ses fichiers (moins les fichiers qu'une autre copie ou un autre torrent lit), et laisse toute copie hoard intacte : voir API REST. L'outil MCP delete_torrents n'existe que si [mcp] allow_destructive = true (voir Serveur MCP).

• Catégories & routage : modes de catégorie, chemins de sauvegarde et décision lors d'un déplacement par catégorie.
• Drain race & graduation : quand le drain met en file des jobs graduate.
• Workflows : actions set_location et delete.
• Nœuds & plusieurs machines : lignes distantes et handoff.
• Visite de l'interface web : sélection, menu contextuel et panneau de progression.
• API REST : toutes les routes citées sur cette page.