rickub
fonzarely/regine-photos-archiverpublic⑂ Fork 0
⑂ 7ceaa34
Branches
main View all branches → View all tags →
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.

workflow

Fabien Champigny committed 2026-09-09T15:37:37+02:00 Browse files
7ceaa34 parent: 90962a1
modified docs/archivage-photo-elements-cles.md +26 -0
@@ -47,6 +47,31 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections
4747 - Conserver le contexte au-delà des images : notes de terrain, correspondance, interviews, planches-contact originales.
4848 - Raconte comment le travail a été fait, pas seulement son résultat.
4949
50+## 9. Workflow d'édition sécurisé : checkout / réconciliation (NAS comme serveur d'archives)
51+
52+Constat de départ : aucune marque de NAS (Synology, QNAP, TrueNAS...) ne permet de mélanger, dans un même dossier partagé, des permissions différentes par type de fichier (ex. RAW en lecture seule, XMP en écriture). Les ACL/permissions NAS fonctionnent par dossier/fichier/utilisateur, pas par extension. Séparer physiquement RAW et XMP dans des dossiers aux droits différents est une option, mais l'alternative retenue pour Régine est de déplacer la protection au niveau applicatif plutôt que filesystem.
53+
54+Principe : Régine gère elle-même l'aller-retour entre l'archive (sur le NAS) et un espace de travail local, avec réconciliation par contenu (hash) avant tout réarchivage. Ça évite d'avoir à bricoler des permissions par extension : l'archive NAS reste un partage normal, et la protection vient du fait que seule Régine lit/écrit l'archive, de façon médiée.
55+
56+Déroulé :
57+
58+- **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).
59+- **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.
60+- **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier :
61+ - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement.
62+ - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement.
63+ - 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.
64+ - 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.
65+ - 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).
66+- 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.
67+
68+Points à anticiper pour l'implémentation :
69+
70+- Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go).
71+- Temps de transfert réseau au moment du checkout.
72+- Verrou/marqueur côté NAS pendant qu'un projet est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle.
73+- Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW.
74+
5075 ## Pistes de fonctionnalités pour Régine
5176
5277 - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison.
@@ -55,6 +80,7 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections
5580 - Détection de doublons / vérification d'intégrité par checksum.
5681 - Gestion de niveaux de sélection (brut / sélection / édition finale).
5782 - Champs de droits/licence par photo ou par lot.
83+- Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 9.
5884
5985 ## Sources
6086
@@ -47,6 +47,31 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections
47 - Conserver le contexte au-delà des images : notes de terrain, correspondance, interviews, planches-contact originales.47 - Conserver le contexte au-delà des images : notes de terrain, correspondance, interviews, planches-contact originales.
48 - Raconte comment le travail a été fait, pas seulement son résultat.48 - Raconte comment le travail a été fait, pas seulement son résultat.
49 49
50+## 9. Workflow d'édition sécurisé : checkout / réconciliation (NAS comme serveur d'archives)
51+
52+Constat de départ : aucune marque de NAS (Synology, QNAP, TrueNAS...) ne permet de mélanger, dans un même dossier partagé, des permissions différentes par type de fichier (ex. RAW en lecture seule, XMP en écriture). Les ACL/permissions NAS fonctionnent par dossier/fichier/utilisateur, pas par extension. Séparer physiquement RAW et XMP dans des dossiers aux droits différents est une option, mais l'alternative retenue pour Régine est de déplacer la protection au niveau applicatif plutôt que filesystem.
53+
54+Principe : Régine gère elle-même l'aller-retour entre l'archive (sur le NAS) et un espace de travail local, avec réconciliation par contenu (hash) avant tout réarchivage. Ça évite d'avoir à bricoler des permissions par extension : l'archive NAS reste un partage normal, et la protection vient du fait que seule Régine lit/écrit l'archive, de façon médiée.
55+
56+Déroulé :
57+
58+- **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).
59+- **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.
60+- **Réconciliation avant réarchivage** : Régine recalcule les hash de la copie de travail et les compare au manifeste pour classer chaque fichier :
61+ - hash RAW/JPEG inchangé + XMP/DOP nouveau ou modifié → cas normal, archivable directement.
62+ - hash RAW/JPEG changé sous le même nom → anomalie (le fichier maître ne devrait jamais être modifié) → à signaler, jamais archivé silencieusement.
63+ - 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.
64+ - 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.
65+ - 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).
66+- 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.
67+
68+Points à anticiper pour l'implémentation :
69+
70+- Espace disque local suffisant pour la copie de travail (un projet RAW peut peser plusieurs dizaines de Go).
71+- Temps de transfert réseau au moment du checkout.
72+- Verrou/marqueur côté NAS pendant qu'un projet est "checké out", pour éviter que deux personnes (ou deux instances de Régine) modifient la même archive en parallèle.
73+- Les protections filesystem (ACL fines, attributs immuables `chattr +i`/`chflags schg`, snapshots immuables DSM 7.2+) restent utiles en filet de sécurité complémentaire, mais plus comme mécanisme principal de protection des RAW.
74+
50 ## Pistes de fonctionnalités pour Régine75 ## Pistes de fonctionnalités pour Régine
51 76
52 - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison.77 - Moteur de métadonnées basé sur IPTC/XMP plutôt qu'un système maison.
@@ -55,6 +80,7 @@ Notes de recherche sur les pratiques d'archivage utilisées pour les collections
55 - Détection de doublons / vérification d'intégrité par checksum.80 - Détection de doublons / vérification d'intégrité par checksum.
56 - Gestion de niveaux de sélection (brut / sélection / édition finale).81 - Gestion de niveaux de sélection (brut / sélection / édition finale).
57 - Champs de droits/licence par photo ou par lot.82 - Champs de droits/licence par photo ou par lot.
83+- Workflow checkout (copie de travail locale) / réconciliation par hash avant réarchivage sur le NAS, plutôt que permissions NAS par type de fichier — cf. section 9.
58 84
59 ## Sources85 ## Sources
60 86