You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
@revolunet a proposé un fix dans #59 (qui est mergé) afin de se prémunir d’une erreur d’écriture lorsqu’un fichier a plus de 255 caractères (problème sous Mac pour @revolunet). Ceci concerne surtout le système d’organisation "sections" où les dossiers correspondent aux titres (parfois longs) et les articles sont dans les dossiers.
En étudiant de mon côté sous Linux (ext4), je constate que c’est chaque fichier qui doit faire moins de 255 caractères, ça serait donc plus souple que ce qui est actuellement dans Archéo Lex (où le chemin total doit faire moins de 255 caractères). @revolunet: est-ce bien cela également sur Mac ?
D’autre part, cette nouvelle version me fait des bugs car ce sont les derniers caractères qui sont conservés donc ça peut sortir du dossier conteneur ("textes" par défaut) puisque l’opération est effectuée après (ceci sera/serait résolu en limitant uniquement chaque niveau à 255 caractères).
Un point de discussion est de prendre le début ou la fin du nom de fichier lorsqu’on tronque. C’est la fin qui est actuellement prise, mais je trouverais plus logique de prendre le début, notamment pour avoir le titre ("Chapitre III", "Paragraphe 2", etc.), mais bien sûr en conservant l’extension (et le début de titre "Article_" le cas échéant).
Aussi, plus précisément, il semble que certains systèmes de fichiers aient un maximum de 255 octets comme ext4 et btrfs, quoique certains semblent avoir 255 caractères (d’après Wikipédia en français). En testant sur Linux avec ext4, ce sont bien des octets (un "é" prend la place de 2 "a").
Enfin, peut-être le plus important : dans une optique de portabilité et de reproductibilité – pour avoir numéros de versions Git reproductibles – il serait souhaitable de définir une limite absolue et non dépendante de la plate-forme, ou en tous cas avoir une option de configuration (comme l’actuelle --dates-git qui permet de gérer les dates avant 1970 mais en rendant les dépôts non-compatibles avec GitHub) qui permette de générer :
soit avec cette limite absolue (probablement 255 qui semble assez standard, au moins Mac et Linux)
soit le maximum possible sur la plate-forme (l’implémentation actuelle)
soit pas de limite (en lien avec Exporter directement au format Git-pack #51, je vais bientôt exporter directement en écrivant les objets Git, donc je pourrai probablement m’affranchir de cette limite, même si je n’ai aucune idée s’il serait alors possible d’ouvrir les dépôts Git créés, donc ce n’est pas non plus forcément souhaitable).
PS : d’après une recherche rapide, sur les versions actuelles des codes, je ne trouve que le "titre XXI bis" du code de procédure pénal qui a un titre (donc un seul niveau) qui fait plus de 255 caractères (271 exactement), mais cela n’empêche qu’il faut traiter le cas.
The text was updated successfully, but these errors were encountered:
Je suis tombé sur cette erreur, voilà le cas exact pour info:
OSError: [Errno 36] File name too long: "textes/arrêtés/arrêté_du_14_juin_1988_modifiant_l'arrêté_du_25_janvier_1985_relatif_à_la_composition,_à_l'organisation_et_au_fonctionnement_de_la_Commission_statutaire_nationale_compétente_pour_les_praticiens_hospitaliers_et_fixant_une_procédure_particulière_pour_des_élections_à_la_section_Radiologie_et_la_section_Pharmacie"
EDIT: On dirait que la limite est faite pour les fichiers mais pas pour les dossiers
@revolunet a proposé un fix dans #59 (qui est mergé) afin de se prémunir d’une erreur d’écriture lorsqu’un fichier a plus de 255 caractères (problème sous Mac pour @revolunet). Ceci concerne surtout le système d’organisation "sections" où les dossiers correspondent aux titres (parfois longs) et les articles sont dans les dossiers.
En étudiant de mon côté sous Linux (ext4), je constate que c’est chaque fichier qui doit faire moins de 255 caractères, ça serait donc plus souple que ce qui est actuellement dans Archéo Lex (où le chemin total doit faire moins de 255 caractères). @revolunet: est-ce bien cela également sur Mac ?
D’autre part, cette nouvelle version me fait des bugs car ce sont les derniers caractères qui sont conservés donc ça peut sortir du dossier conteneur ("textes" par défaut) puisque l’opération est effectuée après (ceci sera/serait résolu en limitant uniquement chaque niveau à 255 caractères).
Un point de discussion est de prendre le début ou la fin du nom de fichier lorsqu’on tronque. C’est la fin qui est actuellement prise, mais je trouverais plus logique de prendre le début, notamment pour avoir le titre ("Chapitre III", "Paragraphe 2", etc.), mais bien sûr en conservant l’extension (et le début de titre "Article_" le cas échéant).
Aussi, plus précisément, il semble que certains systèmes de fichiers aient un maximum de 255 octets comme ext4 et btrfs, quoique certains semblent avoir 255 caractères (d’après Wikipédia en français). En testant sur Linux avec ext4, ce sont bien des octets (un "é" prend la place de 2 "a").
Enfin, peut-être le plus important : dans une optique de portabilité et de reproductibilité – pour avoir numéros de versions Git reproductibles – il serait souhaitable de définir une limite absolue et non dépendante de la plate-forme, ou en tous cas avoir une option de configuration (comme l’actuelle --dates-git qui permet de gérer les dates avant 1970 mais en rendant les dépôts non-compatibles avec GitHub) qui permette de générer :
PS : d’après une recherche rapide, sur les versions actuelles des codes, je ne trouve que le "titre XXI bis" du code de procédure pénal qui a un titre (donc un seul niveau) qui fait plus de 255 caractères (271 exactement), mais cela n’empêche qu’il faut traiter le cas.
The text was updated successfully, but these errors were encountered: