10.12 Sierra Problème pour vider la corbeille

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
76 850
23 603
Forêt de Fontainebleau
Donc actuellement TRIER est bien dans l'espace racine du volume WD 2 To (ce qui montre que l'élément est déplaçable) ? - si oui > passe une commande :
Bloc de code:
ls -lan /Volumes/"WD 2 To"/TRIER

  • qui retourne les permissions sur l'objet (sans montrer le nom de l'utilisateur remplacé par son UID)

=> poste cette ligne ici que je sache quel est le statut de cet élément.
 

shopgame

Membre junior
10 Décembre 2016
21
1
Avec Permanent Eraser, j’entends bien le bruit de la corbeille qui se vide, mais le dossier TRIER est toujours dans la corbeille.

-

Donc actuellement TRIER est bien dans l'espace racine du volume WD 2 To (ce qui montre que l'élément est déplaçable) ?
Oui

-

Bloc de code:
MBPdeAlexandre:~ alexandre$ ls -lan /Volumes/"WD 2 To"/TRIER
total 512
drwxrwxrwx  1 501  20  131072  4 fév  2016 .
drwxrwxrwx  1 501  20  131072 31 déc  1979 ..
MBPdeAlexandre:~ alexandre$
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
76 850
23 603
Forêt de Fontainebleau
C'est donc un dossier - et il est vide d'éléments.

Alors tente encore cette commande (si TRIER est bien toujours à la racine du volume et pas à la corbeille) :
Bloc de code:
sudo mv /Volumes/"WD 2 To"/TRIER /Volumes/"WD 2 To"/RETIF

  • cette commande renomme le dossier TRIER --> RETIF sans le déplacer (si elle passe)

=> est-ce que tu vois à la racine de ton volume que TRIER a disparu remplacé par un dossier RETIF ? - ou passe la commande :
Bloc de code:
ls -ld /Volumes/"WD 2 To"/RETIF

=> est-ce que RETIF est listé ?
 

shopgame

Membre junior
10 Décembre 2016
21
1
Oui il y a un dossier RETIF, TRIER a disparu.

Bloc de code:
MBPdeAlexandre:~ alexandre$ ls -ld /Volumes/"WD 2 To"/RETIF
drwxrwxrwx  1 alexandre  staff  131072  4 fév  2016 /Volumes/WD 2 To/RETIF
MBPdeAlexandre:~ alexandre$
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
76 850
23 603
Forêt de Fontainebleau
Bien ! - ça montre que l'objet est manipulable. On va peut-être finir par l'avoir à l'usure.

Alors nouvelle commande :
Bloc de code:
sudo mv /Volumes/"WD 2 To"/RETIF Desktop

  • cette commande déplace le dossier RETIF de l'espace du volume WD 2 To à... celui de ton Bureau de session.

=> est-ce que le dossier RETIF a disparu de l'espace du volume WD 2 To et est-ce que tu le vois sur ton Bureau de session ? - ou la commande :
Bloc de code:
ls -ld Desktop/RETIF
le liste-t-elle ?
 

shopgame

Membre junior
10 Décembre 2016
21
1
Bloc de code:
MBPdeAlexandre:~ alexandre$ sudo mv /Volumes/"WD 2 To"/RETIF Desktop
Password:
mv: /Volumes/WD 2 To/RETIF: Directory not empty
mv: /bin/rm: terminated with 1 (non-zero) status
MBPdeAlexandre:~ alexandre$

Bloc de code:
MBPdeAlexandre:~ alexandre$ ls -ld Desktop/RETIF
drwxrwxrwx  2 alexandre  staff  68  4 fév  2016 Desktop/RETIF

RETIF est sur le bureau ET le DD.
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
76 850
23 603
Forêt de Fontainebleau
Ah m... toujours ce message d'erreur : « Directory not empty » dont je n'ai pas la clé.

En fait > déplacer un objet (mv) équivaut à 2 actions suivies : le copier à la destination (cp) > le supprimer à la source (rm). Il a donc été copié à la destination (RETIF sur le Bureau) mais pas supprimé à la source (RETIF dans le volume WD 2 To).

Je suppose que la copie est supprimable --> la commande :
Bloc de code:
rm -rf Desktop/RETIF
supprime bien RETIF du Bureau ?

En résumé : le dossier peut bien être renommé > déplacé dans l'espace de son répertoire parent (le volume WD 2 To) > mais pas supprimé pour un motif d'erreur dont la raison m'échappe. Même si l'opérateur est root > même si la session d'opération relève d'un Système étanger à celui de l'OS.

Tu peux encore essayer (concernant le RETIF du volume WD 2 To) un :
Bloc de code:
sudo rm -d -P /Volumes/"WD 2 To"/RETIF

  • qui commande la suppression du dossier avec 3 passes d'effacement sur l'objet

=> mais je conjecture que le même message d'erreur va revenir encore...
 

shopgame

Membre junior
10 Décembre 2016
21
1
RETIF est supprimé du bureau.

Bloc de code:
MBPdeAlexandre:~ alexandre$ sudo rm -d -P /Volumes/"WD 2 To"/RETIF
rm: /Volumes/WD 2 To/RETIF: Directory not empty
Effectivement...
 
D

Deleted member 1099514

Invité
Salut

Petite immiscion (et non immersion) dans votre galère.:D
Ce DDE est formaté ExFat, je suppose qu'il est donc aussi utilisé sous Windows?
Si oui pourquoi ne pas tenter la suppression du répertoire depuis Windows?
Depuis la ligne de commande (hé oui ça existe aussi chez windows) voir la commande rd
 
  • J’aime
Réactions: shopgame

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
76 850
23 603
Forêt de Fontainebleau
dans votre galère
... ouaip ! on a beau r[a]m[er] > ça ne veut rien savoir


Dans ce contexte > je suis curieux de savoir si un logiciel (gratuit) de suppression des éléments récalcitrants réussit à en venir à bout.

Télécharge ici ☞Trash It!☜ > lance l'application > choisis l'option : "Really stuck" --> est-ce que RETIF est supprimé du volume ou toujours pas ?
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
76 850
23 603
Forêt de Fontainebleau
Je me reconnais un tantinet déconfit --> de ne pas capturer la raison de l'erreur (« Directory not empty ») qui bloque la suppression.

À supposer que la commande rm portant sur un répertoire (sans sous-dossiers) et comportant donc l'option recursive procède de "bas en haut" (des enfants au parent) ; càd. supprime le contenu enfant du répertoire avant de supprimer le dossier parent lui-même --> alors tout échec à vider le répertoire de son contenu enfant > bloquerait nécessairement la finalisation de la commande sur le dossier parent. Pour la raison que : « Directory not empty » --> le répertoire parent n'a pas été préalablement vidé de ses éléments enfants.

Cette conjecture (qu'il y aurait une "temporalisation remontante" de la commande : des entants au parent) > permettrait d'interpréter le message d'erreur répétitif --> il y aurait un contenu enfant du dossier non supprimé préalablement par la commande > ce qui bloquerait la suppression du dossier parent qui doit nécessairement être vide (empty = évacué) au moment terminal de sa suppression.

Le problème étant qu'aucune commande ls de listage du contenu du dossier > ne met à jour le moindre contenu du dossier > qui apparaît vide. D'où le paradoxe d'un dossier vide insupprimable parce que non vide.

D'où vient qu'il est considéré comme non-vide alors qu'actuellement il n'a pas de contenu  déterminable ?

  • soit le système de fichiers qui gère le volume comporte des erreurs > de sorte que le dossier qu'on cherche à supprimer ferait l'objet d'une telle erreur du système de fichiers : être faussement représenté comme non-vide, en l'absence d'éléments enfants actuels. Dans ce cas > il faudrait réparer le système de fichiers du volume.

  • soit le dossier à sa création servait bien d'espace local pour un contenu > mais "exogène" à l'espace du volume dans lequel il est recelé. Par exemple, s'il s'agit d'un dossier ayant fonction de "point de montage" (ou autres possibilités : réseau, serveur). Le dossier pourrait-il avoir alors un contenu "fantôme" ? => ce qui me conduit à demander des détails sur son origine : comment a-t-il été créé ? Depuis la session du Mac ? Pour abriter quelle sorte de contenu (photos ou autre) ? En provenance de quelle source ?
 

macomaniac

Ouroboros
Club MacG
20 Septembre 2012
76 850
23 603
Forêt de Fontainebleau
Je retourne sur la brèche.

En cas de tentative de suppression du dossier (actuellement renommé RETIF) par le Finder > le message suivant s'affichait (d'après le message #1 de ce fil) :
Si je tente de vider la corbeille, j’ai ce message : « Impossible d’effectuer l’opération car l’élement « … » est utilisé »

En cas de tentative de suppression du même dossier par la commande rm > le message suivant s'affiche :
Bloc de code:
Directory not empty

L'hypothèse qu'une opération de suppression parcourt la séquence suivante : [vider en préambule le contenu enfant d'un dossier > afin de pouvoir supprimer ensuite ce dossier parent à la condition qu'il soit devenu vide] m'a paru signaler que, malgré les apparences, le dossier RETIF n'est pas évalué comme vide > mais comme recelant une espèce de contenu qui échappe à la suppression > ce qui empêche la suppression consécutive du dossier parent.

Si je connecte le message d'erreur du Finder avec cette idée --> lorsque le volume est monté pour la session de l'utilisateur connecté Alexandre > un (ou des) processus s'adresserai(en)t au dossier RETIF pour y traiter un contenu échappant au listage.

Cette représentation me conduit à tenter une enquête avec la commande lsof (list_open_files : lister les fichiers ouverts). Je vais supposer qu'un « open file » est un élément quelconque (qui peut être aussi bien un dossier qu'un fichier) qui se trouve "ouvert pour lecture" par un processus - càd. « utilisé ».

Alors, shopgame, ton DDE WD 2 To attaché au Mac et le dossier RETIF apparent à la racine de ce volume > passe la commande :
Bloc de code:
sudo lsof -x +D /Volumes/"WD 2 To"/RETIF

  • cette commande cherche "quels éléments sont utilisés par quels processus" en descendant dans le dossier parent ciblé et en traversant le point de montage s'il en est un

=> tu n'as qu'à poster ici le retour de la commande.
 

shopgame

Membre junior
10 Décembre 2016
21
1
Petite immiscion (et non immersion) dans votre galère.

Ce DDE est formaté ExFat, je suppose qu'il est donc aussi utilisé sous Windows?

Alors il y a un moment où je transférais des gros fichiers vidéo de mon ordi portable sous Windows vers mes DD, pour pouvoir les lire sur le MBP. Et depuis un long moment je ne suis jamais ou presque sur Windows, mais oui j’utilisais les DD sur Windows, c’est pourquoi j’ai choisi le format exFat.

-

ce qui me conduit à demander des détails sur son origine : comment a-t-il été créé ? Depuis la session du Mac ? Pour abriter quelle sorte de contenu (photos ou autre) ? En provenance de quelle source ?
Le dossier a été créé sur le DD il me semble, pour classer des archives ou des fichiers vidéo (extraits des archives) (que je déplace du DD vers le MBP ou vice-versa, ou même dans le DD lui-même ; ou que je copie/supprime depuis le DD ou MBP). Ce sont des fichiers que je télécharge depuis des hébergeurs de type rapidgator ou uploaded par exemple, vers le MBP.

-

Y a un détail que j’ai omis et qui peut-être pourra orienter vers une piste : parfois je supprime pas mal de fichiers en même temps dans la corbeille, via « supprimer la sélection », et il arrive que seul un seul ou quelques fichiers soient supprimés, et que je doive m’y reprendre à une ou deux fois pour supprimer les autres c’est-à-dire sélectionner à nouveau les fichiers (plusieurs en même temps ou un par un) dans la corbeille puis choisir « supprimer la sélection » . Et cela depuis le problème avec le dossier récalcitrant. Voilà.

-

Tu as tenté la solution Windows, si tu en as un?

EDIT : Sur un autre ordi, j’ai tenté sur Windows 7, j’ai branché le DDE, supprimé RETIF, puis vidé la corbeille… et bien ça a fonctionné, plus de RETIF sur Windows ni Mac, ni sur le DD ni dans la corbeille des deux OS. J’imagine qu’on ne saura jamais pourquoi ce « bug » est arrivé ?
 
  • J’aime
Réactions: macomaniac

pouppinou

Une vie de Chien et de Pommé, et je suis heureux !
17 Juin 2017
2 249
2 053
49
Niche.
Parfois le côté Obscure l'emporte sur la côté de la Force :D

En tout cas encore une fois merci à toi @macomaniac pour ce cours de logique appliqué via le Terminal et ta façon très didactique qui permet au plus idiot de suivre sans soucis de compréhension ;)
 

shopgame

Membre junior
10 Décembre 2016
21
1
Vous allez être contents, le problème est revenu (fichiers non supprimés après vidage de la corbeille). Ici, c’est sur un autre disque dur externe WD 4 To, en exFat, cette fois-ci avec 2 dossiers récalcitrants (vraisemblablement vides). J’imagine qu’on peut mener une nouvelle investigation ?

Quelques détails en plus : il me semble que ces dossiers étaient situés dans dans un dossier, lui-même dans un dossier… etc. Peut-être 3 ou 4 niveaux de dossiers max jusqu’à la racine du DDE.