Gestionnaire disque NTFS bas niveau ? [Résolu]

[pragmatique]

Bonjour,

Voilà mon problème: un logiciel de backup buggé m'a créé sous windows 7 une arborescence de plus de 950 niveaux de dossiers dont la longueur de chemin totale (plus de 8000 caractères) est à la limite de ce que supporte les API windows.

J'ai tenté toutes les astuces trouvées sur le net pour supprimer ce dossier et ses sous dossiers mais aucune ne fonctionne, même des outils "officiels" microsoft comme robocopy plantent sur ce dossier.

J'ai même tenté d'écrire un bout de code récursif avec les API unicodes pour utiliser la capacité maximum des API windows, mais arrivé à une certaines profondeur (plus de 950 niveaux) la fonction FindFirstFileW échoue et on ne peut plus continuer.

Donc ma question est: existe-t-il un outil bas niveau qui aille taper directement dans le driver NTFS pour corriger ce genre de problèmes (en bypassant les API standard sinon c'est voué à l'échec) ?

NOTE: en soit ce dossier ne me dérange pas, mais par contre il fait planter la plupart des antivirus, antispyware ou outils de recherche sur le disque donc c'est quand même gênant.

[sevyc64]

Quel est le nom du dossier en question ?

Essaye peut-être de démarrer sur un LiveCD linux pour tenter de le supprimer

[pragmatique]

Le nom du dossier n'a pas d'importance, il est juste répété des centaines de fois exemple: c:\dir1\dir1\dir1......

Sinon un livecd linux c'est une idée, mais quel est l'utilitaire qu'il faut utiliser une fois le livecd démarré ?

[sevyc64]

Le nom du dossier peut avoir une importance.

W7 est tellement bien foutu que certains dossiers système ont un sous-dossier qui est en réalité un lien vers le dossier parent. Ce sous dossier a donc lui-même un sous-dossier qui est un lien vers le premier dossier parent et qui a lui-même ce même lien ......

C'est le cas notamment du dossier C:\Users\NomUtilisateur\AppData\Local\
Le sous dossier Application Data étant un lien vers le dossier parent, à lui-même un sous dossier Application Data, qui a lui-même un sous dossier Application Data, qui a lui-même .... et on va comme ça jusqu'au plantage des apis si les logiciels ne savent pas gérer ce cas de figure.

[JML19]

Bonsoir

As-tu fait un essai en démarrage par la touche F8 mode ligne de commande uniquement ou en mode ligne de commande sous windows exécuter en tant qu'administrateur la commande ==> rmdir /S "\\?\[Chemin du dossier]" ?

Attention aux espaces dans le nom du dossier, si tu as nom de dossier inconnu.

[pragmatique]

Alors le dossier est un sous dossier qui démarre dans "c:\users\monuser\mes documents" donc il n'est pas dans appdata.

Pour le rmdir j'ai essayé un cmd.exe en mode admin (au cas ou...) , la commande démarre m'affiche le début du chemin (tronqué donc) en me disant que le dossier n'est pas vide.

Et un "del /s /q" me dit "gnagnagna" (tronqué toujours) est trop long.

J'ai pas encore tenté la manip en mode console F8 mais bon ... je ne vois pas pourquoi ça passerait mieux, je vais essayer.

[sevyc64]

Justement ce dossier "Mes documents" n'est pas un dossier mais un de ces liens merdiques qui peuvent poser problème.

Le dossier "c:\users\monuser\mes documents" représente en réalité le dossier "c:\users\monuser\documents" qui, lui, est un vrai dossier


Edit : Ces dossiers liens sont aussi appelés Point de jonction NTFS

[pragmatique]

Oui je sais que ces dossiers sont des liens mais je ne pense pas dans mon cas que l'origine du problème soit là, en fait c'est une malheureuse boucle infinie de création récursive de dossier qui a créé le problème: elle a atteint les limites de longueur et/ou de nombre de niveaux supportés par l'api windows.

Après le mystère est pourquoi la phase de création à "réussi" en laissant le système de fichiers dans un état incohérent, ça aurait du planter à ce moment là en renvoyant une erreur et il n'y aurait jamais eu de problème d'effacement.

Je vais tester le F8 pour être sur d'avoir tout fait

[Youri30]

Bonsoir,
Je vais peut-être dire une bêtise, mais une idée me traverse l'esprit.
C'est le niveau de profondeur qui pose problème, ou la longueur des chemins en arrivant au fond ?
Si c'est la longueur des chemins, tu peux peut-être tenter de renommer les sous-répertoires en partant du haut, en mettant un nom à un seul caractère à chaque niveau, ça raccourcirait l'ensemble.

[JML19]

Bonsoir

Essais en bootant sur un UBCD.

[pragmatique]

Re bonjour à tous, bon F8 n'a servi à rien comme prévu

Sinon ça n'est pas la longueur totale qui pose problème car j'ai réussi déjà à renommer une partie des sous dossiers en une seule lettre (j'avais testé il y a un moment déjà sans succès).

C'est soit la profondeur qui pose problème, soit le dernier sous dossier (le plus profond) qui a mal été créé dans la table d'allocation (peut être qu'il manque un \0 à la fin ou que sa longueur théorique ne correspond pas à sa longueur réelle du coup le système n'arrive pas à y accèder.

Reste effectivement à booter sur un linux (pas testé encore).
UBCD c'est mort j'avais testé il y a un moment aussi.

Merci en tout cas pour vos suggestions ...

[pragmatique]

Bon j'ai enfin réussi grâce à un linux live cd : après avoir tenté un utilitaire du cd qui a crashé, j'ai opté pour le shell à l'ancienne: "rm -r -f dossier_pourri" et ... quelques minutes plus tard (quand même) j'ai refais fébrilement un "ls" ... oh miracle il n'était plus là

Merci à tous ceux qui ont participé