fonzarely/regine-photos-archiverpublic⑂ Fork 0
⑂ 3f0d339
Commits
⬇ Clone ▾
git clone https://git.rickub.com/fonzarely/regine-photos-archiver.git
git clone ssh://git@rickub.com/fonzarely/regine-photos-archiver.git

Host key fingerprint (ed25519): SHA256:iycHnxEyq0Q7uyVpB7JlznP0G7JrTPXLYRcAU5CSLhc — verify it before your first connect.

upload validation

Fabien Champigny committed 2026-09-11T16:21:42+02:00 Browse files
3f0d339 parent: ffb97b5
modified docs/archivage-photo-elements-cles.md +4 -1
@@ -60,13 +60,16 @@ Déroulé :
6060
6161 - **Checkout** : Régine copie le contenu d'un projet/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3).
6262 - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps.
63+ - **Restauration à la demande.** À tout moment de cette phase, sans attendre le "point avant archive", l'utilisateur peut demander explicitement à Régine de restaurer un fichier qu'il vient d'effacer localement (erreur de manipulation, changement d'avis). Ce n'est pas une fonctionnalité séparée : c'est la même commande de restauration que celle déclenchée par un refus de suppression à la réconciliation (voir plus bas), rendue disponible en continu pendant l'édition plutôt que seulement au moment de la validation finale.
6364 - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier :
6465 - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement.
6566 - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. **Pour DNG/TIFF/JPEG, ce critère doit porter sur le hash image-only (section 12), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.**
6667 - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier de projet entier (ex. transformation d'un projet simple en sous-projet, section 10) — un déplacement massif de fichiers à hash inchangé, pas un cas à part.**
67- - hash du manifeste absent de la copie de travail → suppression → jamais propagée automatiquement ; confirmation explicite de l'utilisateur requise avant de toucher à l'archive.
68+ - hash du manifeste absent de la copie de travail → suppression candidate → jamais propagée automatiquement ; listée explicitement (pas noyée dans un compte global) au "point avant archive", avec confirmation explicite requise fichier par fichier avant de toucher à l'archive.
6869 - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local).
6970 - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS.
71+- **Restauration, le mécanisme commun.** Restaurer un fichier consiste à le retrouver dans l'archive NAS via son identifiant pérenne (cf. section 3) — encore intacte tant que rien n'a été poussé — et à le recopier dans la copie de travail locale, avec vérification checksum comme pour tout autre transfert (section 5). Deux déclencheurs pour la même commande : à la demande de l'utilisateur pendant l'édition (voir "Travail local" ci-dessus), ou automatiquement quand il refuse une suppression candidate au "point avant archive" (voir ci-dessous). Dans les deux cas, le fichier restauré n'est plus une suppression candidate : il retombe dans le cas normal (hash inchangé).
72+- **Refus d'une suppression, fichier par fichier.** Au "point avant archive", chaque suppression candidate se valide indépendamment : accepter, ou refuser. Un refus déclenche la restauration décrite ci-dessus, pas un simple retrait de la liste. L'upload vers l'archive ne démarre qu'une fois que chaque suppression candidate a été traitée, soit acceptée soit restaurée — jamais avec des suppressions encore en attente d'arbitrage.
7073
7174 Points à anticiper pour l'implémentation :
7275
@@ -60,13 +60,16 @@ Déroulé :
60 60
61 - **Checkout** : Régine copie le contenu d'un projet/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3).61 - **Checkout** : Régine copie le contenu d'un projet/répertoire du NAS vers un espace de travail local, et enregistre un **manifeste de référence** pris à cet instant (par fichier : chemin, taille, hash de contenu type SHA-256, identifiant pérenne — cf. section 3).
62 - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps.62 - **Travail local** : édition libre dans la copie de travail (DxO ou autre outil) — RAW renommés/effacés, XMP/DOP créés ou modifiés, exports dérivés générés. Aucune contrainte à imposer ici puisque c'est une copie jetable ; l'archive sur le NAS n'est pas touchée pendant ce temps.
63+ - **Restauration à la demande.** À tout moment de cette phase, sans attendre le "point avant archive", l'utilisateur peut demander explicitement à Régine de restaurer un fichier qu'il vient d'effacer localement (erreur de manipulation, changement d'avis). Ce n'est pas une fonctionnalité séparée : c'est la même commande de restauration que celle déclenchée par un refus de suppression à la réconciliation (voir plus bas), rendue disponible en continu pendant l'édition plutôt que seulement au moment de la validation finale.
63 - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier :64 - **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier :
64 - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement.65 - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement.
65 - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. **Pour DNG/TIFF/JPEG, ce critère doit porter sur le hash image-only (section 12), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.**66 - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement. **Pour DNG/TIFF/JPEG, ce critère doit porter sur le hash image-only (section 12), pas sur le hash fichier entier, sous peine de signaler à tort chaque édition de métadonnées comme une anomalie.**
66 - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier de projet entier (ex. transformation d'un projet simple en sous-projet, section 10) — un déplacement massif de fichiers à hash inchangé, pas un cas à part.**67 - hash retrouvé sous un nom différent → renommage détecté via le **contenu**, pas le nom → proposer de renommer dans l'archive, ou mieux, relier via l'identifiant pérenne plutôt que par chemin. **Ce même mécanisme couvre aussi le déplacement d'un dossier de projet entier (ex. transformation d'un projet simple en sous-projet, section 10) — un déplacement massif de fichiers à hash inchangé, pas un cas à part.**
67- - hash du manifeste absent de la copie de travail → suppression → jamais propagée automatiquement ; confirmation explicite de l'utilisateur requise avant de toucher à l'archive.68+ - hash du manifeste absent de la copie de travail → suppression candidate → jamais propagée automatiquement ; listée explicitement (pas noyée dans un compte global) au "point avant archive", avec confirmation explicite requise fichier par fichier avant de toucher à l'archive.
68 - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local).69 - fichier de la copie de travail sans correspondance dans le manifeste → nouveau fichier (export dérivé, etc.) → politique à définir (archiver aussi, ou laisser en local).
69 - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS.70 - Cette liste de changements classés est exactement le "point avant archive" que l'utilisateur voit et valide avant que Régine n'écrive quoi que ce soit sur le NAS.
71+- **Restauration, le mécanisme commun.** Restaurer un fichier consiste à le retrouver dans l'archive NAS via son identifiant pérenne (cf. section 3) — encore intacte tant que rien n'a été poussé — et à le recopier dans la copie de travail locale, avec vérification checksum comme pour tout autre transfert (section 5). Deux déclencheurs pour la même commande : à la demande de l'utilisateur pendant l'édition (voir "Travail local" ci-dessus), ou automatiquement quand il refuse une suppression candidate au "point avant archive" (voir ci-dessous). Dans les deux cas, le fichier restauré n'est plus une suppression candidate : il retombe dans le cas normal (hash inchangé).
72+- **Refus d'une suppression, fichier par fichier.** Au "point avant archive", chaque suppression candidate se valide indépendamment : accepter, ou refuser. Un refus déclenche la restauration décrite ci-dessus, pas un simple retrait de la liste. L'upload vers l'archive ne démarre qu'une fois que chaque suppression candidate a été traitée, soit acceptée soit restaurée — jamais avec des suppressions encore en attente d'arbitrage.
70 73
71 Points à anticiper pour l'implémentation :74 Points à anticiper pour l'implémentation :
72 75