Bonjour,
Je viens d’installer LibreGED sous Windows et je tiens tout d’abord à vous féliciter : je trouve l’idée du programme vraiment excellente, en particulier la possibilité de gérer un historique des fichiers sans avoir à les déplacer. C’est un concept que j’apprécie énormément. Bravo pour ce travail et pour le partage.
Malheureusement, je suis confronté à un problème que je redoutais un peu. Il semble lié au fait que certains de mes dossiers dépassent la limite fatidique des 259 caractères imposée par Windows.
Je vous joins des captures d’écran illustrant la situation.
À titre d’information, j’utilise également un autre logiciel de sauvegarde (que j’apprécie beaucoup lui aussi) dont le concepteur a réussi à contourner cette limite. Le traitement se fait avec un message d’avertissement, mais les opérations restent possibles. Je joins également une capture d’écran correspondante.
Pensez-vous qu’il serait envisageable d’implémenter un mécanisme similaire dans LibreGED ?
Cela fait près de 40 ans que mes dossiers et sous-dossiers s’enrichissent et s’allongent progressivement. Aujourd’hui, il m’est difficile de tout restructurer. Un autre développeur m’a suggéré de revoir complètement mon arborescence, mais cela me semble complexe et peu réaliste dans mon contexte. D’autant plus que, via des outils comme Total Commander et quelques autres solutions techniques, tout fonctionne parfaitement.
Je garde donc espoir de pouvoir utiliser LibreGED à long terme, car son approche me correspond tout à fait.
Encore bravo pour votre travail et merci par avance pour votre retour.
Cordialement, Guy
Je viens d’installer LibreGED sous Windows et je tiens tout d’abord à vous féliciter : je trouve l’idée du programme vraiment excellente, en particulier la possibilité de gérer un historique des fichiers sans avoir à les déplacer. C’est un concept que j’apprécie énormément. Bravo pour ce travail et pour le partage.
Malheureusement, je suis confronté à un problème que je redoutais un peu. Il semble lié au fait que certains de mes dossiers dépassent la limite fatidique des 259 caractères imposée par Windows.
Je vous joins des captures d’écran illustrant la situation.
À titre d’information, j’utilise également un autre logiciel de sauvegarde (que j’apprécie beaucoup lui aussi) dont le concepteur a réussi à contourner cette limite. Le traitement se fait avec un message d’avertissement, mais les opérations restent possibles. Je joins également une capture d’écran correspondante.
Pensez-vous qu’il serait envisageable d’implémenter un mécanisme similaire dans LibreGED ?
Cela fait près de 40 ans que mes dossiers et sous-dossiers s’enrichissent et s’allongent progressivement. Aujourd’hui, il m’est difficile de tout restructurer. Un autre développeur m’a suggéré de revoir complètement mon arborescence, mais cela me semble complexe et peu réaliste dans mon contexte. D’autant plus que, via des outils comme Total Commander et quelques autres solutions techniques, tout fonctionne parfaitement.
Je garde donc espoir de pouvoir utiliser LibreGED à long terme, car son approche me correspond tout à fait.
Encore bravo pour votre travail et merci par avance pour votre retour.
Cordialement, Guy
Messages
Bonjour Guy et bienvenue sur Technifree !
Merci d'utiliser LibreGED, ça fait toujours plaisir de savoir que ça peut être utile à d'autres
Je vois que tu es victime des soucis NTFS de Windows, c'est regrettable effectivement.
J'aurai bien une réponse, mais elle serait mal venue ici (quoique, je la donne quand même : Linux (son système de fichier est totalement différent et bien plus robuste et fiable que l’archaïque NTFS + Win32)).
Néanmoins, je vais regarder pour voir si un contournement est possible, bien que ce soit dangereux pour l'intégrité des fichiers et surtout pour l'indexage (par Windows et donc par LibreGED).
Il faudrait que je puisse reproduire exactement le soucis sur ma plateforme de développement. Du coup, saurais-tu me dire à combien de niveau de répertoire le message apparaît et aussi la version de Windows que tu utilises ? (Windows 10, Windows 11, 32 ou 64 bits).
Sinon, pour résumer :
-> Oui, c’est envisageable (pas simple à mettre en oeuvre mais pas impossible non plus)
-> Je vais implémenter un mode “résilient”:
- LibreGED continue la réindexation et avertit sur les fichiers/dossiers ignorés (chemin trop long, etc.)
- On va proposer un export/log de la liste
- et on va tenter d'améliorer la compatibilité Windows via support "\\?\ + exe longPathAware" (oui je sais, c'est un peu chinois, mais j'ai mon idée)
C'est clair qu'il serait stupide de refaire 40 ans d'arbo (le conseil qu'on t'a donné est typiquement donné par quelqu’un qui n’a jamais eu de données à gérer, j'ai le même souci que toi - pas en terme d'arborescence mais en quantité de documents depuis plus de 30 ans aussi).
Sans promesses de résultat, je tente
Merci d'utiliser LibreGED, ça fait toujours plaisir de savoir que ça peut être utile à d'autres
Je vois que tu es victime des soucis NTFS de Windows, c'est regrettable effectivement.
J'aurai bien une réponse, mais elle serait mal venue ici (quoique, je la donne quand même : Linux (son système de fichier est totalement différent et bien plus robuste et fiable que l’archaïque NTFS + Win32)).
Néanmoins, je vais regarder pour voir si un contournement est possible, bien que ce soit dangereux pour l'intégrité des fichiers et surtout pour l'indexage (par Windows et donc par LibreGED).
Il faudrait que je puisse reproduire exactement le soucis sur ma plateforme de développement. Du coup, saurais-tu me dire à combien de niveau de répertoire le message apparaît et aussi la version de Windows que tu utilises ? (Windows 10, Windows 11, 32 ou 64 bits).
Sinon, pour résumer :
-> Oui, c’est envisageable (pas simple à mettre en oeuvre mais pas impossible non plus)
-> Je vais implémenter un mode “résilient”:
- LibreGED continue la réindexation et avertit sur les fichiers/dossiers ignorés (chemin trop long, etc.)
- On va proposer un export/log de la liste
- et on va tenter d'améliorer la compatibilité Windows via support "\\?\ + exe longPathAware" (oui je sais, c'est un peu chinois, mais j'ai mon idée)
C'est clair qu'il serait stupide de refaire 40 ans d'arbo (le conseil qu'on t'a donné est typiquement donné par quelqu’un qui n’a jamais eu de données à gérer, j'ai le même souci que toi - pas en terme d'arborescence mais en quantité de documents depuis plus de 30 ans aussi).
Sans promesses de résultat, je tente
Bonjour Vincent,
Merci pour ta réponse rapide et constructive, c’est vraiment sympa.
Il est malheureusement trop tard pour moi pour basculer vers Linux. Mon expérience me fait penser qu’il vaut mieux éviter de trop se disperser : je ne rattraperais probablement jamais sous Linux toute l’expérience accumulée sous Windows, même si tu as certainement raison sur le fond.
Je me doute de la difficulté à gérer « proprement » les noms de dossiers dépassant les 259 caractères, surtout quand on sait que Windows continue de gérer les noms de fichiers au format 8.3. Pour ceux qui en douteraient, il suffit de lancer la commande dir /X dans une fenêtre de commande "cmd" ( autre que le terminal proposé
) pour le constater
Pour information, je travaille sous Windows 11 (j’ai tout de même un peu évolué depuis MS-DOS 1.0). J’ai d’ailleurs développé toute une gestion de disques virtuels à l’aide de batchs et de la commande SUBST, ce qui me permet d’atteindre facilement des niveaux de sous-répertoires très importants sans souci pour pouvoir les exploiter et TotalCommander fait parfaitement le job pour les sauvegardes. Je salue l'auteur ici car, même si il ne s'agit pas d'un logiciel open source, le prix de sa License "à vie" est des plus correct.
Cela pourrait peut-être constituer une piste de réflexion pour la gestion des chemins longs, d’autant que cela permet également d’affecter des dossiers distants via des adresses IP... Je pense que cette commande DOS ne pourra jamais totalement disparaître des couches basses de Windows, sans remettre en question toute la gestion des fichiers, notamment côté gestionnaires réseau.
Autre petite information : je travaille avec FreeCAD depuis des années et je crois me souvenir que, sur d’anciennes versions, je n’avais pas ce souci, ce qui tendrait à dire qu’il doit être possible de le gérer. Je vais essayer de réinstaller ces vieilles versions pour voir à quel moment cela a basculé, ou s’il s’agit plutôt d’un problème côté Windows qui serait devenu plus restrictif ?
En tout cas, merci encore d’avoir pris ma demande en considération, et bravo pour le programme, le site, le forum et le blog etc... : je suis bluffé.
@+
Cordialement, Guy
Merci pour ta réponse rapide et constructive, c’est vraiment sympa.
Il est malheureusement trop tard pour moi pour basculer vers Linux. Mon expérience me fait penser qu’il vaut mieux éviter de trop se disperser : je ne rattraperais probablement jamais sous Linux toute l’expérience accumulée sous Windows, même si tu as certainement raison sur le fond.
Je me doute de la difficulté à gérer « proprement » les noms de dossiers dépassant les 259 caractères, surtout quand on sait que Windows continue de gérer les noms de fichiers au format 8.3. Pour ceux qui en douteraient, il suffit de lancer la commande dir /X dans une fenêtre de commande "cmd" ( autre que le terminal proposé
) pour le constaterPour information, je travaille sous Windows 11 (j’ai tout de même un peu évolué depuis MS-DOS 1.0
). J’ai d’ailleurs développé toute une gestion de disques virtuels à l’aide de batchs et de la commande SUBST, ce qui me permet d’atteindre facilement des niveaux de sous-répertoires très importants sans souci pour pouvoir les exploiter et TotalCommander fait parfaitement le job pour les sauvegardes. Je salue l'auteur ici car, même si il ne s'agit pas d'un logiciel open source, le prix de sa License "à vie" est des plus correct.Cela pourrait peut-être constituer une piste de réflexion pour la gestion des chemins longs, d’autant que cela permet également d’affecter des dossiers distants via des adresses IP... Je pense que cette commande DOS ne pourra jamais totalement disparaître des couches basses de Windows, sans remettre en question toute la gestion des fichiers, notamment côté gestionnaires réseau.
Autre petite information : je travaille avec FreeCAD depuis des années et je crois me souvenir que, sur d’anciennes versions, je n’avais pas ce souci, ce qui tendrait à dire qu’il doit être possible de le gérer. Je vais essayer de réinstaller ces vieilles versions pour voir à quel moment cela a basculé, ou s’il s’agit plutôt d’un problème côté Windows qui serait devenu plus restrictif ?
En tout cas, merci encore d’avoir pris ma demande en considération, et bravo pour le programme, le site, le forum et le blog etc... : je suis bluffé.
@+
Cordialement, Guy
Bonsoir Vincent,
Pour faire suite à mon message précédent, j'ai réinstallé la version 0.18 de FREECAD pour vérifier son comportement avec les dernières versions et j'ai constaté que le problème était identique.
Ce que j'ai constaté :
- Il est possible de créer une arborescence de fichiers qui peut dépasser allègrement les 259 caractères : Sous DOS, la commande "md C:\A0123456789\B0123456789\C0123456789\D0123456789\E0123456789\F0123456789\G0123456789\H0123456789\I0123456789\J0123456789\K0123456789\L0123456789\M0123456789\N0123456789\O0123456789\P0123456789\Q0123456789\R0123456789\S0123456789\T0123456789\U0123456789\V0123456789\W0123456789\X0123456789\Y0123456789\Z0123456789" génère l'arborescence des dossiers sans souci et "rd C:\A0123456789\B0123456789\C0123456789\D0123456789\E0123456789\F0123456789\G0123456789\H0123456789\I0123456789\J0123456789\K0123456789\L0123456789\M0123456789\N0123456789\O0123456789\P0123456789\Q0123456789\R0123456789\S0123456789\T0123456789\U0123456789\V0123456789\W0123456789\X0123456789\Y0123456789\Z0123456789" l'efface de la même manière
Ensuite j'ai constaté que le dossier qui pose limite avec FREECAD, et précisé par TotalCommander, est T0123456789 mais son comportement est différent si on est sous DOS ou dans l'explorateur Windows !
- Sous FREECAD je peux lire tous les fichiers jusqu'au sous-dossier T0123456789 mais je ne peux plus les réécrire à partir de ce sous-dossier et pour les fichiers plus loin dans l'arborescence j'obtiens :
Vous remarquerez qu'il traite tout au format 8.3
- Sous DOS ou dans l'explorateur Windows on peut renommer les fichiers ou les copier dans des dossiers encore plus profond de la hiérarchie sans aucun problème ce qui semblerait indiquer qu'il n'y a plus de limite
En conclusion, il semblerait que ce sont uniquement les programmes tiers qui posent souci, Microsoft semble avoir trouvé le moyen de dépasser les 259 caractères fatidique !
Je reste à votre disposition si vous souhaitez que je teste autre chose...
Bon courage et merci encore
Pour faire suite à mon message précédent, j'ai réinstallé la version 0.18 de FREECAD pour vérifier son comportement avec les dernières versions et j'ai constaté que le problème était identique.
Ce que j'ai constaté :
- Il est possible de créer une arborescence de fichiers qui peut dépasser allègrement les 259 caractères : Sous DOS, la commande "md C:\A0123456789\B0123456789\C0123456789\D0123456789\E0123456789\F0123456789\G0123456789\H0123456789\I0123456789\J0123456789\K0123456789\L0123456789\M0123456789\N0123456789\O0123456789\P0123456789\Q0123456789\R0123456789\S0123456789\T0123456789\U0123456789\V0123456789\W0123456789\X0123456789\Y0123456789\Z0123456789" génère l'arborescence des dossiers sans souci et "rd C:\A0123456789\B0123456789\C0123456789\D0123456789\E0123456789\F0123456789\G0123456789\H0123456789\I0123456789\J0123456789\K0123456789\L0123456789\M0123456789\N0123456789\O0123456789\P0123456789\Q0123456789\R0123456789\S0123456789\T0123456789\U0123456789\V0123456789\W0123456789\X0123456789\Y0123456789\Z0123456789" l'efface de la même manière
Ensuite j'ai constaté que le dossier qui pose limite avec FREECAD, et précisé par TotalCommander, est T0123456789 mais son comportement est différent si on est sous DOS ou dans l'explorateur Windows !
- Sous FREECAD je peux lire tous les fichiers jusqu'au sous-dossier T0123456789 mais je ne peux plus les réécrire à partir de ce sous-dossier et pour les fichiers plus loin dans l'arborescence j'obtiens :
Vous remarquerez qu'il traite tout au format 8.3
- Sous DOS ou dans l'explorateur Windows on peut renommer les fichiers ou les copier dans des dossiers encore plus profond de la hiérarchie sans aucun problème ce qui semblerait indiquer qu'il n'y a plus de limite
En conclusion, il semblerait que ce sont uniquement les programmes tiers qui posent souci, Microsoft semble avoir trouvé le moyen de dépasser les 259 caractères fatidique !
Je reste à votre disposition si vous souhaitez que je teste autre chose...
Bon courage et merci encore
Hello,
Je vois bien le problème (qui n'en est pas un en réalité).
Ton arborescence est correcte, même sous Windows et son système de fichier NTFS, il faut juste que LibreGED s'adapte à celle-ci. Chose que je n'avais pas prévu au départ étant donné que je limite de base la longueur des chemins à 240 caractères (je n'utilise pas les "longpath" dans LibreGED et pourtant, Python le permet).
Du coup, il faut que j'adapte mon Logiciel à cette situation, car, si tu es concerné, d'autres risquent de l'être également. FreeCAD n'a malheureusement pas jugé bon, dans ses dernières versions, d'implémenter ceci (tout comme moi d'ailleurs). Il est vrai que la gestion de fichiers en 8.3 nous permet quand même d'aller (théoriquement) jusqu'à +32000 caractères (ça c'est sur le papier chez Kro$oft, car je n'ai jamais testé).
Je vais donc adapter LibreGED à cette situation que tu soulève très précisément (et je t'en remercie au passage), le temps pour moi de réécrire certaines parties du code.
Par contre, je rebondis sur ta phrase :
J'ai vu passer sous linux bien des personnes qui m'affirmaient la même chose et qui, aujourd'hui, me disent l'inverse :
Je peux t'accompagner (même personnellement s'il le faut) pour t'aider à faire la bascule, il faut juste avoir confiance et y croire
Je suis là pour ça !
PS : ce soucis avec Freecad n'existe pas sous linux vu que le logiciel est natif sur cet OS ! (j'dis ça ... j'dis rien ... hein ^_^)
Je vois bien le problème (qui n'en est pas un en réalité).
Ton arborescence est correcte, même sous Windows et son système de fichier NTFS, il faut juste que LibreGED s'adapte à celle-ci. Chose que je n'avais pas prévu au départ étant donné que je limite de base la longueur des chemins à 240 caractères (je n'utilise pas les "longpath" dans LibreGED et pourtant, Python le permet).
Du coup, il faut que j'adapte mon Logiciel à cette situation, car, si tu es concerné, d'autres risquent de l'être également. FreeCAD n'a malheureusement pas jugé bon, dans ses dernières versions, d'implémenter ceci (tout comme moi d'ailleurs). Il est vrai que la gestion de fichiers en 8.3 nous permet quand même d'aller (théoriquement) jusqu'à +32000 caractères (ça c'est sur le papier chez Kro$oft, car je n'ai jamais testé).
Je vais donc adapter LibreGED à cette situation que tu soulève très précisément (et je t'en remercie au passage), le temps pour moi de réécrire certaines parties du code.
Par contre, je rebondis sur ta phrase :
Il est malheureusement trop tard pour moi pour basculer vers Linux. Mon expérience me fait penser qu’il vaut mieux éviter de trop se disperser : je ne rattraperais probablement jamais sous Linux toute l’expérience accumulée sous Windows, même si tu as certainement raison sur le fond.
J'ai vu passer sous linux bien des personnes qui m'affirmaient la même chose et qui, aujourd'hui, me disent l'inverse :
Mais pourquoi diable suis-je resté aussi longtemps enfermé dans Windows, si j'avais su que linux était aussi simple et intuitif, j'y serai passé depuis très longtemps !
Je peux t'accompagner (même personnellement s'il le faut) pour t'aider à faire la bascule, il faut juste avoir confiance et y croire
Je suis là pour ça !
PS : ce soucis avec Freecad n'existe pas sous linux
vu que le logiciel est natif sur cet OS ! (j'dis ça ... j'dis rien ... hein ^_^)
Bonjour,
Je vois le soucis : il-y-a deux endroits où les liens symboliques n'ont pas le paramètre "target_is_directory=True" dans le code.
Sur Windows, un "symlink" vers un dossier créé sans ce paramètre est traité comme un lien symbolique de fichier uniquement, donc "os.walk" ne le traverse pas et du coup les dossiers n'apparaissent pas dans l'arborescence. C'est un comportement spécifique à Windows qui n'existe pas sous Linux.
(il est vrai aussi que je n'ai pas de sauvegarde complète de ma ged réalisée sous windows, étant sous linux de base, je ne l'ai pas vu tout de suite).
Bon, je corrige cela ...
En ce qui concerne les notifications, effectivement, je n'ai pas implémenté cette fonctionnalité pour éviter tout souci de sécurité éventuel. Je n'utilise pas les adresses mail des membres du site, elle ne sert qu'à éviter le spam lors de l'inscription au forum (je ne voulais pas coder un forum trop intrusif). Peut-être dans une future évolution du site ...
Par contre, en se connectant de temps en temps au forum, on peut voir en haut l'évolution des sujets (lié au cookie) :
Je vois le soucis : il-y-a deux endroits où les liens symboliques n'ont pas le paramètre "target_is_directory=True" dans le code.
Sur Windows, un "symlink" vers un dossier créé sans ce paramètre est traité comme un lien symbolique de fichier uniquement, donc "os.walk" ne le traverse pas et du coup les dossiers n'apparaissent pas dans l'arborescence. C'est un comportement spécifique à Windows qui n'existe pas sous Linux.
(il est vrai aussi que je n'ai pas de sauvegarde complète de ma ged réalisée sous windows, étant sous linux de base, je ne l'ai pas vu tout de suite).
Bon, je corrige cela ...
En ce qui concerne les notifications, effectivement, je n'ai pas implémenté cette fonctionnalité pour éviter tout souci de sécurité éventuel. Je n'utilise pas les adresses mail des membres du site, elle ne sert qu'à éviter le spam lors de l'inscription au forum (je ne voulais pas coder un forum trop intrusif). Peut-être dans une future évolution du site ...
Par contre, en se connectant de temps en temps au forum, on peut voir en haut l'évolution des sujets (lié au cookie) :
Bonjour Vincent,
Je ne t’ai pas oublié !
J’ai encore un souci avec un dossier volumineux qui fait planter le programme (il s’arrête sans message spécifique).
Avant de conclure que cela provient de l’application, je préfère m’assurer que le problème ne vient pas de Windows, et plus particulièrement de Ntfs.sys, qui m’a déjà posé des problèmes par le passé. Je suis donc en train de faire des tests pour déterminer si le souci vient d’un sous-dossier ou d’un fichier en particulier.
Il faut dire que si ce dossier est validé par LibreGED, cela repoussera très loin les limites des 5 000 documents différents déjà testés avec l’application.
Je reviens vers toi dès que possible. Mais avec tout ce que j’ai en cours, il me faudrait presque des journées de 48 heures !
Cordialement,
Guy
Je ne t’ai pas oublié !
J’ai encore un souci avec un dossier volumineux qui fait planter le programme (il s’arrête sans message spécifique).
Avant de conclure que cela provient de l’application, je préfère m’assurer que le problème ne vient pas de Windows, et plus particulièrement de Ntfs.sys, qui m’a déjà posé des problèmes par le passé. Je suis donc en train de faire des tests pour déterminer si le souci vient d’un sous-dossier ou d’un fichier en particulier.
Il faut dire que si ce dossier est validé par LibreGED, cela repoussera très loin les limites des 5 000 documents différents déjà testés avec l’application.
Je reviens vers toi dès que possible. Mais avec tout ce que j’ai en cours, il me faudrait presque des journées de 48 heures !
Cordialement,
Guy
Bonjour Vincent,
Je viens de tester rapidement la nouvelle version 2.6.3. Voici mes premiers constats, sans pouvoir encore tirer de conclusions définitives :
Contrairement à la version 2.6.2, l’indexation des fichiers du dossier semble bien se lancer et s’exécuter pendant plusieurs minutes. Toutefois, le bandeau d’avancement reste bloqué à 0 %.
En parallèle, j’observe une activité du programme dans le gestionnaire des tâches (utilisation mémoire fluctuante), et les ventilateurs s’activent, ce qui laisse penser que le traitement est bien en cours.
Après environ 10 minutes, malgré un affichage toujours à 0 %, le programme se ferme, comme avec la version 2.6.2.
Si je tente ensuite de relancer l’application, elle ne démarre plus. En insistant une seconde fois, j’obtiens un message d’erreur
puis, à la troisième tentative, un écran bleu mentionnant Fltmgr.sys, suivi d’un redémarrage après vidage de la mémoire.
Après le redémarrage, le programme ne se relance toujours pas.
Premières observations :
Après réflexion, cela pourrait correspondre à un comportement de type bouclage ou doublons liés aux liens, ce qui pourrait constituer une piste à explorer.
Question subsidiaire :
Sur de gros dossiers, si l’indexation peut durer plusieurs minutes — ce qui n’est pas un problème en soi — serait-il possible d’ajouter un indicateur visuel (type sablier ou message) pour signaler que le programme est en cours de traitement, en complément du bandeau d’avancement ?
Ce comportement semble également se produire au démarrage, lorsque le programme effectue un traitement qui peut le bloquer avant d’apparaître.
Autres remarques / demandes :
Suggestions :
Je vais poursuivre mes tests afin de déterminer si le problème provient d’un dossier ou d’un fichier spécifique dans l’arborescence, et je vous tiendrai informé dès que j’aurai plus d’éléments.
Merci encore pour tout ce travail accompli.
Cordialement,
Guy
Je viens de tester rapidement la nouvelle version 2.6.3. Voici mes premiers constats, sans pouvoir encore tirer de conclusions définitives :
Contrairement à la version 2.6.2, l’indexation des fichiers du dossier semble bien se lancer et s’exécuter pendant plusieurs minutes. Toutefois, le bandeau d’avancement reste bloqué à 0 %.
En parallèle, j’observe une activité du programme dans le gestionnaire des tâches (utilisation mémoire fluctuante), et les ventilateurs s’activent, ce qui laisse penser que le traitement est bien en cours.
Après environ 10 minutes, malgré un affichage toujours à 0 %, le programme se ferme, comme avec la version 2.6.2.
Si je tente ensuite de relancer l’application, elle ne démarre plus. En insistant une seconde fois, j’obtiens un message d’erreur
puis, à la troisième tentative, un écran bleu mentionnant Fltmgr.sys, suivi d’un redémarrage après vidage de la mémoire.
Après le redémarrage, le programme ne se relance toujours pas.
Premières observations :
- Il est nécessaire de supprimer le dossier avorté dans le répertoire "files". Une fois le dossier supprimé, le programme réapparaît avec toute l’arborescence du dossier supprimé, comme si sa présence bloquait l’application. Certains sous-dossiers restent toutefois manquants dans la colonne de gauche et le nombre de fichiers GED reste à 1.
- Si je relance l’indexation, le dossier est bien supprimé et tout redevient cohérent.
- Le fait que le dossier libreged_win (contenant les fichiers de traitement et l’exécutable) et/ou d’autres anciennes versions de libreged_win soient situés dans un sous-dossier du dossier à indexer semble poser plus de problèmes que si je les sors dans des dossiers externes. L’indexation est beaucoup plus rapide dans ce cas, même si le programme s’arrête également, mais beaucoup plus rapidement.
- Les sous-dossiers manquants apparaissent à partir du traitement de ce(s) dossier(s), ce qui semble confirmer un lien avec leur présence ou les liens vers ces dossiers dans l’arborescence.
- Au moins une fois, j’ai pu obtenir une hiérarchie cohérente avec un nombre de fichiers très important en GED (bien supérieur à 1), mais je n’arrive plus à reproduire cette situation (je n’ai pas fait de copie écran).
Après réflexion, cela pourrait correspondre à un comportement de type bouclage ou doublons liés aux liens, ce qui pourrait constituer une piste à explorer.
Question subsidiaire :
Sur de gros dossiers, si l’indexation peut durer plusieurs minutes — ce qui n’est pas un problème en soi — serait-il possible d’ajouter un indicateur visuel (type sablier ou message) pour signaler que le programme est en cours de traitement, en complément du bandeau d’avancement ?
Ce comportement semble également se produire au démarrage, lorsque le programme effectue un traitement qui peut le bloquer avant d’apparaître.
Autres remarques / demandes :
- Dans la colonne de gauche, un dossier de type "lien" s’affiche en bleu clair. Dans la page de droite, cette couleur semble également être utilisée pour des sous-dossiers qui ne sont pas des liens.
- Comportement étrange : un sous-dossier nommé "SOUS-DOSSIER TEST" à gauche s’affiche en "TEST" à droite "SOUS-DOSSIER " a sauté.
- De même, les fichiers contenus dans les dossiers à gauche apparaissent bleu foncé, alors qu’ils sont plutôt verts dans la page de droite.
Suggestions :
- Différencier le message de suppression “Êtes-vous sûr de vouloir supprimer les éléments sélectionnés ? Cette action est irréversible” lorsqu’il s’agit d’un lien ou d’un dossier. Pour un lien, seul le lien est supprimé et cela ne comporte pas de risque ; le message pourrait refléter cette distinction.
- Lorsqu’il s’agit d’un lien, serait-il éventuellement possible de rajouter automatiquement "lien vers" à son nom ou de le mettre en couleur plus distinctive pour éviter toute ambiguïté ?
Je vais poursuivre mes tests afin de déterminer si le problème provient d’un dossier ou d’un fichier spécifique dans l’arborescence, et je vous tiendrai informé dès que j’aurai plus d’éléments.
Merci encore pour tout ce travail accompli.
Cordialement,
Guy
Bonsoir Vincent,
Tout d’abord, voici la manière dont je procède pour installer une nouvelle version :
J’ai créé un dossier nommé « LibreGED » qui regroupe tout ce qui concerne l’application.
Cette méthode me permet de conserver un historique des versions et de relancer rapidement une version antérieure pour effectuer des tests, simplement en jouant sur le renommage des dossiers avec, bien sur, des sous-dossiers "files" différents pour chaque version.
À noter : au départ, le dossier « LibreGED » se trouvait dans le dossier « PROJET », mais je l’ai déplacé en dehors afin d’éviter d’éventuels conflits.
Voici quelques points constatés lors de mes tests :
Comportement observé lors de tests plus poussés :
Avec la séquence suivante :
j’arrive à débloquer la situation et à obtenir un résultat motivant de 796354 fichiers
Cependant, même si tous les dossiers semblent bien présents, le compteur de fichiers ne correspond pas avec celui obtenu par "propriétés" de Window<, ce qui laisse penser qu’une partie de l’indexation est incohérente ou incomplète.
Je poursuis mes investigations. @+
Cordialement,
Guy
PS : Malgré ces points, bravo encore, c’est un vrai plaisir à l’usage ! Le défilement des noms de fichiers et dossiers lorsqu’ils sont trop longs est particulièrement appréciable. Comme tout le reste, c’est vraiment bien pensé — Microsoft pourrait s’en inspirer, plutôt que de nous faire attendre l’affichage complet des noms avec la souris dessus… quand cela fonctionne, ce qui n’est pas toujours le cas !
Tout d’abord, voici la manière dont je procède pour installer une nouvelle version :
J’ai créé un dossier nommé « LibreGED » qui regroupe tout ce qui concerne l’application.
- Je commence par renommer l’archive de la version précédente en y ajoutant son numéro de version :
« libreged_win.7z » devient « libreged_win Vx.x.x.7z » - Je fais de même pour le dossier décompressé correspondant :
« libreged_win » devient « libreged_win Vx.x.x » - Je télécharge ensuite la nouvelle version sous forme d’archive « libreged_win.7z », que je décompresse dans le dossier proposé « libreged_win ».
- Je lance enfin le programme « LibreGED.exe » directement depuis ce dossier.
Cette méthode me permet de conserver un historique des versions et de relancer rapidement une version antérieure pour effectuer des tests, simplement en jouant sur le renommage des dossiers avec, bien sur, des sous-dossiers "files" différents pour chaque version.
À noter : au départ, le dossier « LibreGED » se trouvait dans le dossier « PROJET », mais je l’ai déplacé en dehors afin d’éviter d’éventuels conflits.
Voici quelques points constatés lors de mes tests :
- Sans pouvoir l’affirmer avec certitude, j’ai l’impression que l’indexation fonctionne mieux lorsque LibreGED est exécuté en tant qu’administrateur. Cela pourrait être lié à l’accès à certains fichiers nécessitant des droits étendus.
- Le bargraph de progression de l’indexation reste à 0 %, puis disparaît.
Peut-être cela est-il dû au fait que je teste actuellement sur un seul dossier, et que la progression est basée uniquement sur les dossiers de premier niveau, sans tenir compte des sous-dossiers (passage de 0 % à 100 % avec disparition du bargraph sans avoir eu le temps de voir 100% ). - Au lancement du programme, j’ai l’impression qu’une opération préalable (réindexation ou autre traitement) est effectuée avant l’affichage de l’interface.
Il est possible que cela m’ait induit en erreur en relançant le programme trop rapidement, alors qu’un traitement était encore en cours, ce qui pourrait expliquer certains messages d’erreur observés.
Comportement observé lors de tests plus poussés :
Avec la séquence suivante :
- lancement du programme avec tentative d'intégration du dossier " PROJET " sous forme de lien
- crash du programme sans messages ( bargraph de progression bloqué sur 0% puis disparition de l'interface du programme)
- relancement du programme qui semble "bouclé" en arrière plan sans visuel ( Parfois il a fallu rebooter avant !)
- suppression du "lien" du dossier « PROJET » dans « files » qui débloque le programme et le visuel
- puis réintégration du lien de ce dossier récupéré dans la corbeille Windows
j’arrive à débloquer la situation et à obtenir un résultat motivant de 796354 fichiers
Cependant, même si tous les dossiers semblent bien présents, le compteur de fichiers ne correspond pas avec celui obtenu par "propriétés" de Window<, ce qui laisse penser qu’une partie de l’indexation est incohérente ou incomplète.
Je poursuis mes investigations. @+
Cordialement,
Guy
PS : Malgré ces points, bravo encore, c’est un vrai plaisir à l’usage ! Le défilement des noms de fichiers et dossiers lorsqu’ils sont trop longs est particulièrement appréciable. Comme tout le reste, c’est vraiment bien pensé — Microsoft pourrait s’en inspirer, plutôt que de nous faire attendre l’affichage complet des noms avec la souris dessus… quand cela fonctionne, ce qui n’est pas toujours le cas !
Rebonjour Vincent,
Un autre point me semble important à clarifier :
Dans l’explorateur de fichiers Windows, les « liens » de dossiers créés par votre application apparaissent avec le type « Dossier de fichiers ».
Or, sous Windows, un lien créé de manière classique est généralement un « raccourci » (.lnk), identifié comme tel.
Dans mon cas, mon dossier « PROJET » contient de nombreux raccourcis, que j’utilise pour naviguer rapidement entre différents emplacements. J’ai constaté que votre programme les interprète correctement comme fichiers (et peut-être, plus tard, comme de vrais raccourcis pour changer de dossiers), et non comme des dossiers, ce qui est cohérent.
À noter que, comme vous le savez, Windows distingue plusieurs types de liens (raccourcis, liens symboliques, jonctions), certains étant vus comme de simples fichiers, d’autres comme de véritables dossiers. Il est donc possible que les liens créés par votre application s’apparentent à des jonctions ou des liens symboliques, ce qui expliquerait leur affichage.
Il me semble avoir compris, et mes tests semblent le confirmer, que vous gérez les liens que vous générez comme des raccourcis, et que leur suppression ne supprime pas le contenu des dossiers liés avec leurs fichiers. Cependant, vous comprendrez que, dans le cas d’un lien, un petit commentaire précisant que seul le raccourci sera effacé serait rassurant pour l’utilisateur avant de valider la suppression, surtout lorsque le programme est utilisé principalement pour gérer des liens sans jamais toucher aux dossiers et fichiers.
Je ne sais pas encore comment il serait possible d'intégrer facilement celle-ci dans votre programme afin qu’il reste le plus sobre possible, comme vous l’avez souhaité. Mais une fonction supplémentaire permettant, par défaut, de désactiver (puis éventuellement d'activer facilement) toutes modifications (renommage, effacement, déplacement, etc.) lorsqu’il s’agit d’un lien serait la bienvenue.
Merci pour votre compréhension. J’espère ne pas paraître trop exigeant et ne pas passer pour le « casse-c..illes de service » , c’est uniquement dans l’intérêt de tous et pour contribuer à enrichir votre programme, qui est déjà remarquable.
Cordialement,
Guy
Un autre point me semble important à clarifier :
Dans l’explorateur de fichiers Windows, les « liens » de dossiers créés par votre application apparaissent avec le type « Dossier de fichiers ».
Or, sous Windows, un lien créé de manière classique est généralement un « raccourci » (.lnk), identifié comme tel.
Dans mon cas, mon dossier « PROJET » contient de nombreux raccourcis, que j’utilise pour naviguer rapidement entre différents emplacements. J’ai constaté que votre programme les interprète correctement comme fichiers (et peut-être, plus tard, comme de vrais raccourcis pour changer de dossiers
), et non comme des dossiers, ce qui est cohérent.À noter que, comme vous le savez, Windows distingue plusieurs types de liens (raccourcis, liens symboliques, jonctions), certains étant vus comme de simples fichiers, d’autres comme de véritables dossiers. Il est donc possible que les liens créés par votre application s’apparentent à des jonctions ou des liens symboliques, ce qui expliquerait leur affichage.
Il me semble avoir compris, et mes tests semblent le confirmer, que vous gérez les liens que vous générez comme des raccourcis, et que leur suppression ne supprime pas le contenu des dossiers liés avec leurs fichiers. Cependant, vous comprendrez que, dans le cas d’un lien, un petit commentaire précisant que seul le raccourci sera effacé serait rassurant pour l’utilisateur avant de valider la suppression, surtout lorsque le programme est utilisé principalement pour gérer des liens sans jamais toucher aux dossiers et fichiers.
Je ne sais pas encore comment il serait possible d'intégrer facilement celle-ci dans votre programme afin qu’il reste le plus sobre possible, comme vous l’avez souhaité. Mais une fonction supplémentaire permettant, par défaut, de désactiver (puis éventuellement d'activer facilement) toutes modifications (renommage, effacement, déplacement, etc.) lorsqu’il s’agit d’un lien serait la bienvenue.
Merci pour votre compréhension. J’espère ne pas paraître trop exigeant et ne pas passer pour le « casse-c..illes de service » , c’est uniquement dans l’intérêt de tous et pour contribuer à enrichir votre programme, qui est déjà remarquable.
Cordialement,
Guy
Je viens de publier une version 2.6.4 tenant compte de ces modifications. Pas simple à tout corriger et implémenter, mais je pense avoir pu avancer dans le sens de la demande.
Certaines fonctionnalités ne sont pas applicables en l'état, ça m'obligerait à revoir une trop grande partie du code, dont des fonctions qui marchent plutôt bien actuellement, mais j'ai fait le maximum pour me rapprocher du besoin.
A vos tests
voir ici pour la fiche mise à jour -> https://technifree.com/assets/fiches/LibreGED.html
et ici pour les modifications apportées -> https://technifree.com/fOfO/topic.php?id=214#post-2146
Certaines fonctionnalités ne sont pas applicables en l'état, ça m'obligerait à revoir une trop grande partie du code, dont des fonctions qui marchent plutôt bien actuellement, mais j'ai fait le maximum pour me rapprocher du besoin.
A vos tests
voir ici pour la fiche mise à jour -> https://technifree.com/assets/fiches/LibreGED.html
et ici pour les modifications apportées -> https://technifree.com/fOfO/topic.php?id=214#post-2146
Connectez-vous pour répondre.