5.2 GIT clone file too long

Support
1

Bonjour,

nous sommes en phases de migration vers la 5.2.16 (nous sommes en 5.1.45). J’ai un problème avec les nouveautés git.
Lorsque je clone clone le repo sur mon PC (windows 10) j’ai les erreurs suivantes :

image
image729×337 14.1 KB

J’ai configuré le référentiel en indiquant localhost comme c’était en 5.1 comme valeur par défaut.

image
image1140×501 24.2 KB

Merci de votre aide,
Thierry

2

Je vais laisser @Francois vous expliquer la logique arborescente des nouveaux exports JSON explosés et les nommages qui en decoulent.

Pour lever globalement la limite de longueur de paths niveau windows il faut visiblement aller bidouiller dans la base de registre (ex: https://www.howtogeek.com/266621/how-to-make-windows-10-accept-file-paths-over-260-characters/), je n’ai jamais fait ça et ne peut donc pas garantir que ça marche ou que ça ne posera pas des problèmes par ailleurs => à voir avec le support Windows.

Sinon ça se traite visiblement aussi au niveau Git (coté client), cf. 3 Ways to Fix Git Clone "Filename too long" Error in Windows [Fixed] | JavaProgramTo.com, là aussi je n’ai jamais eu à le faire donc je ne sais pas si ça marche ou s’il y a des contraintes => à tester et à voir avec le support Git

Enfin vous pouvez aussi limiter la taille de ses nommages, ex: renommer votre liste de valeur de LADLADDEMANDEURTYPEPIECEIDENTITE en LAD_DEM_TYP_PI ou dans le genre

3

Bonjour,

Effectivement ce nouveau type d’export en fichiers JSON éclatés respecte la hiérarchie des objets en nommant les répertoires à partir des clés fonctionnelles de objets. C’est tout l’intérêt par exemple d’avoir le paramétrage d’un objet dans un seul répertoire du nom de l’objet.

  • A ce titre, l’export en fichier archive passe par un format tar.gz, car le format ZIP bride également la longueur max d’un path depuis la racine,
  • Sur Windows, nous n’avions jamais rencontré ce problème de longueur, on va investiguer pour essayer de trouver une solution, mais c’est un peu comme une vieille base ORACLE qui limite les noms des table/colonne/index… on ne pourra pas faire des miracles sauf à tronquer les noms générés (à cause du maillon faible) au risque d’avoir des ambiguïtés de clés fonctionnelles dans l’autre sens / à l’import ou au diff du module = donc par exemple devoir gérer une table d’index des clés / path tronqués dans un fichier à la racine du module exporté.

Il faut à priori autoriser les path longs sur le client GIT :

git config --system core.longpaths true

mais suivant votre client GIT ça peut ne pas fonctionner.

En attendant de trouver une solution sur Windows

  • comme le suggère David, vous pouvez renommer vos objets “longs” pour être passant sur Windows :
  • ou utiliser un format non éclaté : le fichier JSON unique contient la même hiérarchique d’objets
  • ou utiliser le format XML éclaté qui n’a pas de hiérarchie métier mais des répertoires par type d’entité
5

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

6

Bonjour

Je refais monter le sujet…

Effectivement, sous Windows (dans mon cas un Windows 11 avec un file system NTFS) quand on a des chemins complets dont la taille est importante (à priori > 260 caractères) Windows ne gère pas correctement les fichiers :

  • L’explorateur les voit
  • On n’arrive pas à les ouvrir (ex: dans un simple éditeur de texte)
  • On arrive bien à les supprimer
  • On arrive pas à les déplacer
  • Etc.

Sur certaines opérations on a ce message:
image
Sur d’autres ça ne dit rien…

Sur Linux pas de souci avec les chemins à rallonge (testé avec le même export de module). @scampano j’imagine que sur Mac c’est OK aussi…

Bref ce format JSON éclaté 5.2+ et Windows ne font pas bon ménage à moins de se restreindre dans les nommages (dans mon cas j’ai atteint la limite en configurant un treeview avec de nombreux “étages”).

@Francois vois-tu une manière de pendre en compte cette limitation technique de Windows tout en conservant l’intérêt une arborescence “hiérarchique” qui est humainement plus lisible et aide au diff/merge hors Simplicité. J’avoue ne pas avoir trop d’idée magique sur ce point…

PS: pour mémoire voici une commande Linux pour trouver les fichiers dont le chemin est > à une certaine longueur (ici 255):

tar tvfz MonModule.tar.gz | awk '{ print $NF }' | awk '{ if (length > 255) printf "%-5s %s\n", length, $0 }' | sort
7
8

PS:

Visiblement à partir de Windows 10 il y a une méthode officielle (documentation Microsoft) peut lever - volontairement - cette limitation par défaut à 260 caractères via une valeur ad hoc dans la base de registre: Maximum Path Length Limitation - Win32 apps | Microsoft Learn

Je n’ai pas encore testé…

9

Ah bon Windows n’est pas fait pour comparer des modèles relationnels de taille variable ?
Oui il faut chercher une solution côté Microsoft si on peut débrider les postes développeurs.

Sinon pas le choix que de tronquer applicativement quelque part, mais ça aura un impact

  • les noms logiques (cf les “~1” de windows)
  • ou la profondeur de l’arbre (260 c’est pas ouf niveau profondeur avec des clés sur 100, mon minitel devait faire pareil)

Dans les 2 cas, ça posera un pb de bijection entre la clé fonctionnelle et le chemin physique d’un objet

  • qui sert au diff uniquement,
  • n’est pas utile dans le cas d’import/export qui scanne les répertoires sans logique autre que de trier les entités pour refaire un XML

Pour un diff, cela oblige à avoir à la racine une correspondance fichier/table des noms physiques = nom logique, lourd car dénormalise en cas dde mise à jour manuelle…

Bref le maillon le plus faible fera encore revenir en arrière le reste qui était plus lisible.
A défaut de solution simple, on ne fera plus d’arbre, on reviendra à un répertoire par type d’objet.
Et faudra pas dire que c’est pas pratique.