Problème corbeille 10.8.5 et Yosemite 10.10.2

[albert13]

J'avais un blem récurrent avec ma corbeille avec OSX 10.8.5, j'ai fait la màj vers Yosemite et idem.
Quand je veux jeter un élément ds ma corbeille, il ne veut pas le stocker dedans, il me propose de le supprimer immédiatement...
Je suis allé voir "Google mon ami", j'ai trouvé quelques manip terminal (dont je ne suis pas fan) et rien y fait. J'ai essayé de faire apparaitre le dossier caché .Trash avec Find any file, je l'ai bien trouvé mais pas possible d'effacer ce dossier...
Bien sûr il y a toujours la solution d'une clean install mais pas bcp de temps devant moi pour ré-installer tout et je ne sais pas comment va se comporter ma ré-installe de la suite adobe CS5... donc j'essaie d'être prudent...
Y a t'il une recette miracle ou une autre manie à faire sur le Terminal ?
la manip que j'ai trouvé date de 2012 :
http://www.theobouzige.fr/archives/3570

Merci pour votre aide

 

[FrançoisMacG]

Quand il existe un dossier .Trash (ou Corbeille) caché à la racine de la Maison, la manœuvre décrite est bonne, à condition de relancer la session immédiatement après :
ça recrée une corbeille toute neuve, avec les bons droits.

Quand il n'y a plus de .Trash (ou Corbeille), il faut le recréer (avec mkdir).

 

[boddy]

Bonjour,

Ou... réinitialisation des ACL :

Démarrer avec Alt et choisir Recovery HD. En haut : Utilitaires - lancer le Terminal et taper : resetpassword. On arrive dans Utilitaire de réinitialisation des mots de passe : choisir dossier Utilisateur. En bas Réinitialisation des permissions et ACL.

 

[albert13]

Bonjour,

Ou... réinitialisation des ACL :

Démarrer avec Alt et choisir Recovery HD. En haut : Utilitaires - lancer le Terminal et taper : resetpassword. On arrive dans Utilitaire de réinitialisation des mots de passe : choisir dossier Utilisateur. En bas Réinitialisation des permissions et ACL.

MERCI c'est sympa boddy, j'ai appliqué ta méthode et cela à l'air ok
J'ai une clé USB (recovery) avec Lion dessus, j'ai donc démarré dessus et j'ai suivi tes instructions
Je suis surpris en ayant fait ma màj de Moutain Lion vers Yosémite depuis AppStore de ne pas avoir de répertoire de secours (si je ne dis pas de bêtises) dans mon DD pour démarrer dessus…
Ou alors "chuis" à côté de la plaque et il faut que je m'en crée un nouveau comme j'ai fait pour clé USB avec Lion dessus.
faut que je retrouve comment j'avais fait. Je crois que j'avais suivi la procédure de Guillaume Gete (Grand Monsieur du Mac) ;-))

sans oublier de dire Merci aussi à FrançoisMacG mais pas pu faire la manip : pas très bon en "mkdir" => dialoguer avec le terminal, ce machin truc n'est pas ma tasse de thé, sauf si j'ai une procédure "bête et méchante"...

 

[Anonyme]

Je suis surpris en ayant fait ma màj de Moutain Lion vers Yosémite depuis AppStore de ne pas avoir de répertoire de secours .

Tu as bien une partition Récupération sous Yosemite, mais elle n'est plus visible en bootant avec la touche Alt : on y accède en bootant avec Cmd + r.

Sinon, comme l'a dit François, il suffisait de quitter/relancer la session pour recréer la corbeille après l'avoir supprimée dans le terminal.

 

[albert13]

Tu as bien une partition Récupération sous Yosemite, mais elle n'est plus visible en bootant avec la touche Alt : on y accède en bootant avec Cmd + r.

Sinon, comme l'a dit François, il suffisait de quitter/relancer la session pour recréer la corbeille après l'avoir supprimée dans le terminal.

Tu as raison Renaud31 j'ai bien ma partition de récup en démarrant avec Cmd+r, no blem, je te remercie.
je ne comprends pas en revanche pourquoi elle n'apparait pas qd je redémarre avec la touche option enfoncée !??!
En fait je n'ai que mon DD qui apparait et pas la partition Recovery…
J'ai essayé aussi de me faire une clé USB avec yosemite ligth dedans mais pas arrivé. J'y étais arrivé il y a une paire d'années avec Diskmaker mais là même avec le version 3.8 niet mon ordi ne veut rien savoir ;-(
Tant pis je vais m'en faire une, en téléchargeant sur mon ordi Yosémite complet et ensuite je l'installe normalement sur ma clé comme si c'était un nouveau DD.

 

[Anonyme]

je ne comprends pas en revanche pourquoi elle n'apparait pas qd je redémarre avec la touche option enfoncée !??!

C'est un choix d'Apple, depuis Yosemite.

Pour faire une clé d'install de Yosemite, n'utilise pas DiskMakerX, mais le Terminal : https://support.apple.com/fr-fr/HT5856

 

[albert13]

C'est un choix d'Apple, depuis Yosemite.

Pour faire une clé d'install de Yosemite, n'utilise pas DiskMakerX, mais le Terminal : https://support.apple.com/fr-fr/HT5856

IMPECC cette procédure je la recommande à tout le monde, elle me semble même mieux et plus sûr qu'avec Dismaker
un GRAND MERCI Renaud31

Albert

 

[FrançoisMacG]

C'est un choix d'Apple, depuis Yosemite.

Ma partition Récupération 10.10 s'affiche en démarrant avec Alt : je n'ai pas activé le mot de passe du programme interne, je n'ai pas activé FileVault, et j'ai effacé le CoreStorage (en activant puis désactivant FileVault) sur mon nouveau Mac livré avec Yosemite.

 

[Anonyme]

Alors quel est le facteur qui "cache" la partition Recovery ? Filevault, ou le CoreStorage ?

 

[FrançoisMacG]

FileVault, c'est sûr : c'est comme ça depuis la naissance de FileVault 2 sous Lion.

Le CoreStorage, c'est indispensable à FileVault,
et d'après ton expérience, ça bloquerait le mode Alt même sans FileVault : à confirmer (ou à demander à macomaniac !).

 

[Anonyme]

D'après ce que j'ai pu lire, le format CoreStorage rend la partition Recovery invisible à l'écran de démarrage (Alt au boot).

Mon Yosemite a été installé par màj sur un clone Mavericks, donc pas de CoreStorage, pas de FileVault.

MAIS, cette installation n'avait pas créé de Recovery, je l'ai créée à posteriori, juste pour tester.

CSK va nous expliquer ça par le menu.

 

[Membre supprimé 1060554]

À l'instar des moustaches des chats qu'alertent d'infimes signaux dans la nuit, les antennes du macomaniac ont frémi à l'inspection de ce fil comme à l'abord d'une mine épistémologique...

Le format CoreStorage a été inventé par les ingénieurs de la Pomme à l'époque de «Lion 10.7», lorsqu'il s'agissait d'abandonner le chiffrement de type : «FileVault-1» (qui ne concernait que le Home_Folder de l'utilisateur), pour passer à un chiffrement de type : «FileVault-2» (qui concernait le Volume entier de l'OS et non plus le dossier de départ d'un utilisateur).

Je me figure qu'il y a eu une analogie dans les problématiques. Si «FileVault-1» était capable de chiffrer le Home_Folder d'un utilisateur qui en faisait le choix, c'était parce qu'une conversion formelle de ce dossier au statut de "Volume" était opérée au préalable --> un disque virtuel était créé (= une image-disque : .sparsebundle) dont le Volume-Image était chiffré et ne montait qu'à condition qu'une clé de déchiffrement soit activée par le renseignement du mot-de-passe d'utilisateur. Si «FileVault-2» de son côté est capable de chiffer le Volume entier de l'OS, c'est parce qu'une conversion formelle là encore s'opère de la partition du disque physique réel concernée (la /dev/disk0s2 en règle générale) --> un Disque Physique Virtuel se trouve "associé" à cette partition entière (= un Physical Volume) dont le Volume Logique correspondant est chiffré et ne monte là encore qu'à condition qu'une clé de déchiffrement soit activée par le renseignement du mot-de-passe d'utilisateur.

Le format dit : CoreStorage est le procédé logique qui transforme la partition régulière d'un disque physique réel en l'équivalent d'une image-disque intégrale (une espèce de .sparsebundle indissociable formellement et équivalente en taille) : un Disque Physique Virtuel, à partir duquel monte un Volume Logique de la même façon qu'un Volume-Image monte à partir d'une Image-Disque locale. Le Groupe de Volumes Logiques (Physical Volume --> Logical Volume Family --> Logical Volume) est l'architecture Disque Virtuel / Volume Virtuel du CoreStorage qui correspond à l'architecture Image-Disque / Volume-Image du .sparsebundle.

D'après cette analogie formelle des problématiques, il m'apparaît que ce qui peut être chiffré, c'est toujours un Volume Virtuel dépendant d'un Disque Virtuel, et non pas un Volume Actuel dépendant d'un Disque Réel. Il semble qu'il faille que le volume concerné soit l'équivalent intégral (en terme d'espace) du support-disque, ce qui n'est pas possible lorsque ce support est un Disque Physique Réel, car ce qui correspond alors à un volume est toujours une partition, càd. un sous-ensemble spatial comparé au support. Alors que, quand on a affaire à un Disque Virtuel, ce n'est pas une partition qui est chiffrée, mais un Volume équivalent en espace à l'ensemble de son support (qu'il s'agisse du Volume-Image d'une Image-Disque ou du Volume Logique d'un Disque Physique Virtuel).

C'est après «Lion 10.7» que les ingénieurs de la Pomme se sont aperçus que les potentialités de ce format CoreStorage qu'il avaient créé à l'origine uniquement pour pouvoir chiffrer le volume de l'OS par analogie avec la manière dont ils chiffraient auparavant le dossier de départ de l'utilisateur (recours à un Volume Virtuel supporté par un Disque Virtuel) - en fait débordaient cet usage étroit, en permettant par exemple le «Fusion Drive» : l'intégration de plusieurs Disques Physiques Virtuels (conversions des partitions d'autant de disques physiques réels distincts qu'on voudra) et la capacité de ne faire rejeter sur cette base composite qu'un seul Volume Logique.

«Yosemite 10.10» a innové, entre autres, parce que le Programme d'Installation de cet OS induit fréquemment à l'install la conversion formelle de la partition-support (/dev/disk0s2 couramment), de format jhfs+ standard, au format CoreStorage quand bien même «FileVault-2» n'est pas activé, non plus qu'un «Fusion Drive» opéré. C'est comme si une condition logique générale se trouvait mise en place, indépendamment de ses conséquences particulières. Comme si le format CoreStorage, dans l'esprit des ingénieurs de la Pomme, avait pris une valeur universelle en soi, de par ses potentialités multiples, aussi bien actuelles qu'à venir, et méritait par là de devenir le format par défaut affectant la partition concernée du disque physqiue réel. Comme si le CoreStorage avait une puissance encore incomplètement actualisée.

Ce format CoreStorage implique de nombreux désagréments qui se résument à des restrictions de la liberté de manœuvre de l'utilisateur. Je ne sais pas si ma susceptibilité équivaut à un combat d'arrière-garde ici, mais je constate que, dès lors qu'un format CoreStorage existe sur la partition de l'OS, alors : le volume de l'OS, devenu Volume Logique dans sa dépendance exclusive d'un Disque Physique Virtuel, est rendu inextensible par les programmes à la disposition de l'utilisateur (il ne peut être ni élargi en taille, ni subdivisible en sous-volumes, par le recours à l'«Utilitaire de Disque», càd. au programme UNIX diskutil). Seuls, le programme de création de la «Recovery HD» comme celui d'une partition-Windows de l'«Assistant BootCamp» permettent dans le sens de l'aller de subdiviser le Volume Logique créé pour générer à côté de lui un volume de la «Recovery HD» ou de «Windows» comme partitions du disque physique réel. Mais ces programmes sont incapables, dans le sens du retour, de réallouer dynamiquement les espaces de ces volumes (si on veut les supprimer) à celui du Volume Logique --> il y a irréversibilité de la division (comme une espèce de loi de l'entropie logique).

Un autre de ces désagréments est l'impossibilité de l'affichage du volume de la «Recovery HD» à l'écran de choix du disque de démarrage affiché par l'option de boot : "alt" (obligation de la commande directe ⌘R pour atteindre l'environnement de la «Recovery HD»). Je ne sais pas pourquoi, exactement, il y a ainsi occultement du volume de la «Recovery HD» mais c'est un fait certain. C'est le format CoreStorage sur la partition de l'OS le responsable, qu'il ait été appliqué "tout seul" (pour du beurre, en l'état actuel des choses, en quelque sorte), ou qu'il soit la condition du chiffrement «FileVault-2». «FileVault-2» n'en est pas responsable en tant qu'agent de chiffrement, mais parce qu'en condition de possibilité de tout chiffrement du volume de l'OS «FileVault-2» commence toujours par convertir cette partition au format CoreStorage (comme j'ai tenté de l'expliquer ci-dessus). C'est donc toujours le CoreStorage, avec ou sans «FileVault-2», qui soustrait le volume de la «Recovery HD» à l'écran de choix du disque de démarrage ("alt").

--------------------​

On peut vérifier cet état de choses par un petit exercice absolument bénin malgré les apparences : admis un OS actuel «Yosemite» (ou «Mavericks» d'ailleurs) installé régulièrement sur la partition /dev/disk0s2 du disque-base du Mac (SSD ou HDD), passer dans le «Terminal» la commande :

sudo diskutil coreStorage convert /dev/disk0s2

suffit en une poignée de secondes à virer le format jhfs+ du volume de l'OS au format CoreStorage avec génération d'un Groupe de Volumes Logiques à 3 instances (Physical Volume --> Logical Volume Family --> Logical Volume) --> re-démarrer le Mac pour "asseoir" le nouveau format et avec la touche "alt" accéder à l'écran de choix du disque de démarrage --> le volume de la «Recovery HD» brille par son ... absence.

Retour au «Terminal». Passer en préalable la commande :

diskutil cs list

de manière à faire s'afficher en retour de commande le tableau de distribution des 3 instances du Groupe de Voluymes Logiques correspondant au format CoreStorage de la partition de l'OS --> en fin de tableau, sélectionner et copier par ⌘C l'UUID de 32 caractères alpha-numériques XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX du Logical Volume (Volume Logique) --> enchaîner avec la commande

sudo diskutil coreStorage revert  XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXX

[en collant l'UUID à sa place dans la commande] et en une poignée de secondes encore le format CoreStorage est détruit et le volume de l'OS restitué au standard jhfs+ en mode live (préservation de l'OS, de ses données, de son caractère bootable) --> re-démarrer encore le Mac pour finir de dissiper les "apparences" du CoreStorage avec la touche d'option "alt" pour accéder à l'écran de choix du disque de démarrage --> le volume de la «Recovery HD» brille par sa ... présence.

​

 

[FrançoisMacG]

Ce format CoreStorage implique de nombreux désagréments qui se résument à des restrictions de la liberté de manœuvre de l'utilisateur.

​

Et d'après d'autres fils où tu es intervenu , le Core Storage semble empêcher autant la réinstallation du Système que la restauration d'une sauvegarde Time Machine à partir des utilitaires de la partition Recovery.

C'est un carcan.

 

[Membre supprimé 1060554]

«La rose est sans pourquoi : elle fleurit, parce qu'elle fleurit» (Angelus Silesius)​

François.

Même si l'invention du format CoreStorage remonte déjà à l'OS «Lion 10.7», j'y suis resté (comme beaucoup d'autres utilisateurs de Macs je présume) complètement étranger jusqu'à la publication de «Yosemite 10.10». Ce, parce que n'ayant jamais utilisé de «Fusion Drive» ni ne recourant au chiffrement du volume de l'OS par «FileVault-2», je n'avais donc aucune raison de "rencontrer" ce format (que ces 2 procédés impliquent comme condition) où que ce soit sur aucun volume dont j'avais l'usage. Avec «Yosemite 10.10», autre musique : indépendamment même d'un «Fusion Drive» ou du chiffrement du volume de l'OS par «FileVault-2», ne voilà-t-il pas que l'installateur de l'OS s'employait (pas à tous les coups mais dans de nombreux cas) à instaurer "à l'insu du plein gré" de l'utilisateur ce format CoreStorage sur la partition majeure dédiée à l'OS (/dev/disk0s2) du disque du Mac? Sans raison déterminée. Sans règle évidente du pourquoi dans tel cas et pas dans tel autre? Sans modalité constante du caractère réversible ou non réversible de ce format.

Si encore le format CoreStorage n'intervenait que comme condition nécessaire & suffisante soit du chiffrement du volume de l'OS, soit de la création d'un «FusionDrive» - alors il aurait été possible de le considérer à tout coup comme impliqué par une décision libre de l'utilisateur. Mais tel n'est pas le cas, puisqu'il arrive que ce format se trouve greffé par l'installateur de «Yosemite» sur la partition de l'OS sans que cela découle d'un choix libre de l'utilisateur. Et le problème de cet événement involontaire, c'est qu'il ne relève pas d'une nécessité logique en soi, mais d'une accidentatlité irrationnelle : pourquoi ce greffon, alors même que l'OS tournerait tout aussi bien contenu dans un volume de format standard? Pourquoi cela arrive-t-il dans certaines occurrences ordinaires d'installation, et pas dans d'autres? Pourquoi, quand cela arrive, est-ce tantôt selon la modalité du réversible et tantôt de l'irréversible?

Il y a là un jeu d'accidents logiques que je trouve pénibles à admettre intellectuellement parlant - parce que l'informatique est présentée comme un Système de causalité déterministe, où la seule volonté de l'utilisateur devrait introduire des "commencements absolus" qui relèvent de la liberté et, lorsque ce n'est pas le cas, parce qu'on a affaire à des erreurs logiques dans la conception de la compatibilité des processus déterministes. Or ici, on a affaire à une espèce de Loi du Hasard qui distribue les cartes inégalement (tantôt oui, tantôt non ; si oui, tantôt réversible, tantôt irréversible ; si oui, sans pourquoi) lors de la mise en place du Système Déterministe de l'OS.

Avec des conséquences inéquitables du point de vue de la liberté des utilisateurs :

♤ un utilisateur A (comme moi, par exemple), sans CoreStorage, garde la pleine puissance de l'outil diskutil sur le schéma du partitionnement de son disque complet et donc la maîtrise "plastique" de cette distribution ; la pleine lisibilité graphique (dans la GUI de l'«Utilitaire de Disque» débogué) de la distribution des volumes utiles ; le plein emploi encore du Disk_Manager (l'afficheur des volumes démarrables déclenché par l'option "alt") ; la pleine puissance de la capacité de l'«Assistant BootCamp» à ré-intégrer en mode "live" l'espace d'une partition Windows qu'on souhaite supprimer au volume principal de l'OS "par-dessus la tête" de la «Recovery HD» intercalée ; la pleine capacité à utiliser l'intercepteur de boot : «rEFInd» comme instance de démarrage.

♧ un utilisateur B, avec CoreStorage (quoique sans les services d'un «FusionDrive» ou d'un chiffrement «FileVault-2» du volume de l'OS qui nécessitent ce format comme condition logique), voit la puissance de l'outil diskutil bloquée (puisqu'il ne peut pas re-dimensionner en mode live le volume de son OS) ; est confronté à une illisibilité graphique du partitionnement de son disque dans la GUI de l'«Utilitaire de Disque» ; ne "voit" plus la «Recovery HD» comme volume démarrable à l'écran de choix du disque de démarrage ; voit la capacité de l'«Assistant BootCamp» de ré-intégrer l'espace d'une partition Windows au volume de l'OS bloquée par le format CoreStorage qui verrouille le Volume Logique ; ne peut plus utiliser l'intercepteur de boot «rEFInd» comme interface de démarrage optionnel (le logiciel se trouve neutralisé par le CoreStorage).​

☞ pourquoi l'utilisateur B, alors même que le CoreStorage qu'il n'a pas choisi ne lui sert absolument à rien, devrait-il être inégal en liberté par rapport à l'utilisateur A sans CoreStorage - tout cela parce qu'une simple Loi du Hasard a fait que, par le plus pur des accidents logiques inauguraux, le 1er ait à subir les conséquences d'une contingence : l'accident du CoreStorage ; tandis que le 2è ait à profiter des avantages d'une autre contingence : l'absence de l'accident du CoreStorage?

Quand on sait le marathon logistique impliqué par la suppression d'un format CoreStorage (irréversible) sur la partition de l'OS (parce que la suppression de toutes les données recelées est impliquée par l'élimination du Volume Logique dans ces conditions - la méthode consistant à activer «FileVault-2» pour chiffrer dans un 1er temps le volume de l'OS, puis à désactiver «FileVault-2» afin de déchiffer ce même volume ne produisant pas nécessairement et dans tous les cas de figures une conversion du volume au format standard jhfs+ mais maintenant dans certains cas le format CoreStorage sans qu'on sache pourquoi --> par conséquent, n'étant pas une solution non-destructrice universelle cf. par exemple ☞Impossible de récupérer l'espace libre (volume Boot Camp)☜) - je trouve qu'il y a là une injustice logique dérivant de la simple contingence du Hasard.

 

[FrançoisMacG]

'il arrive que ce format se trouve greffé par l'installateur de «Yosemite» sur la partition de l'OS sans que cela découle d'un choix libre de l'utilisateur. Et le problème de cet événement involontaire, c'est qu'il ne relève pas d'une nécessité logique en soi, mais d'une accidentatlité irrationnelle : pourquoi ce greffon, alors même que l'OS tournerait tout aussi bien contenu dans un volume de format standard? Pourquoi cela arrive-t-il dans certaines occurrences ordinaires d'installation, et pas dans d'autres?

Deux infos qui devraient atténuer ton sentiment d'irrationalité :

- un facteur au moins semble intervenir dans la décision d'infliger ou pas du Core Storage lors d'une mise à niveau vers Yosemite : le hardware du Mac.

- le Core Storage a d'autres fonctions que l'accès à FileVault et Fusion Drive (Apple le confirme).