copier/coller et glisser/déposer impossible

[ludom13]

Bonsoir a tous,

J'ai un souci depuis aujourd'hui, j'ai cherché sur les forums mais rien n'a résolu mon problème:
Alors que tout allait bien, depuis ce matin je ne peut plus copier coller (que se soit des fichiers ou du texte) ni faire des glisser déposer. C'est apparu sans raison car tout marchait bien avant.

Voici les différentes techniques que j'ai essayé :
reset PRAM.
Reparer les autorisation avec utilitaire de disque
Idem avec onyx + netoyage.
creer un autre compte utilisateur pour voir si le probleme persiste (il persiste).
safe mode (ne change rien)

Je ne peux pas reinstaller OS tout de suite, c'est pourquoi je vous demande votre aide.

Je suis sous leopard (10.5.8) et j'ai un macbook mid 2009. mon disque dur est en externe (car le cable en interne est mort)
La seule chose que j'ai faite hier c'est netoyer un peut le bordel en supprimant des fichiers que j'utilise plus.
Merci d'avance pour votre aide !

---------- Nouveau message ajouté à 19h29 ---------- Le message précédent a été envoyé à 18h50 ----------

Apres toute une journée de recherche je viens finalement de trouver une solution qui marche!

Je vous la poste si quelqu'un un jour a le meme soucis :

dans le terminal :

sudo -s
(type password)
mkdir /tmp
chmod -R 1777 /tmp

logout, login, and that's it.

Pour moi c'est la seule solution qui a marché !

Merci a tous







Note de la modération: pas trop de rapport avec les portables Mac, je déplace dans le forum adéquat.

 

[pascalformac]

penser à cliquer"résolu"( menu outils de discussion)

 

[Membre supprimé 1060554]

Alors que tout allait bien, depuis ce matin je ne peut plus copier coller (que se soit des fichiers ou du texte) ni faire des glisser déposer. C'est apparu sans raison car tout marchait bien avant.


La seule chose que j'ai faite hier c'est nettoyer un peu le bordel en supprimant des fichiers que j'utilise plus.


Apres toute une journée de recherche je viens finalement de trouver une solution qui marche! ...dans le terminal :

sudo -s
(type password)
[B]mkdir /tmp[/B]
chmod -R 1777 /tmp

Si je puis me permettre en toute légère 'ironie' ne tirant pas à conséquence puisque le problème est 'résolu' : le problème signalé n'est pas apparu 'sans raison', mais 'en raison' d'une initiative fâcheuse de nettoyage. Puisque la solution grâce au «Terminal» a consisté en un mkdir /tmp qui équivaut à la création d'un répertoire 'tmp' dans l'espace-racine de l'OS /, il paraît clair que le nettoyage à concerné ledit dossier dont la fonction est d'accueillir les fichiers temporaires écrits par des programmes dans des sous-dossiers intitulés 'launch'. S'agissant d'éléments-système invsibles par défaut, le susdit nettoyage n'a pu se faire 'a la mano' qu'après commande d'affichage des fichiers et dossiers invisibles.

♢​

Là où, pour un émule de Sherlock Holmes qui vient de reconstituer les circonstances du 'crime', la situation devient intéressante malgré son caractère proclamé 'résolu', c'est que : aucun répertoire 'tmp' ne doit être présent en tant que tel à la racine de l'OS. Non, mais un lien symbolique : ⤻tmp pointant le répertoire 'tmp' qui doit se trouver situé à l'intérieur du super-répertoire 'private' qui, lui, est localisé à la racine de l'OS.

À la racine de l'OS, il y a donc un super-répertoire 'private' contenant les sous-répertoires : 'etc', 'var' et 'tmp'. Mais, pour des raisons d'accessibilité on_launch (au démarrage) de l'espace de ces sous-répertoires par le processus 'launchd', 3 liens symboliques se trouvent extrapolés hors du répertoire 'private' dans l'espace-racine de l'OS, qui pointent ces sous-répertoires : '⤻etc', '⤻var' et '⤻tmp'.

Il paraît clair que l'opération de nettoyage des :

fichiers que j'utilise plus

a porté sur l'espace-racine de l'OS rendu indûment visible, et éliminé le lien symbolique : '⤻tmp' pointant le sous-répertoire 'tmp' du répertoire 'private' (lequel n'est aucunement une 'propriété privative' malgré son nom pouvant induire en erreur s'il s'affichait visiblement). Et la 'solution' trouvée sur le Net a consisté a remplacer le lien symbolique : '⤻tmp' supprimé lors du 'nettoyage' par un répertoire : 'tmp' présent à la racine de l'OS où il ne devrait pas exister. Il y aurait donc 2 répertoires : 'tmp' en fonction actuellement, un contenu dans le super-répertoire 'private' de la racine de l'OS, un contenu en-dehors de 'private' dans ce même espace-racine en strict parallélisme à 'private'. Càd. 2 répertoires incommunicants.

J'admire (au sens Cartésien du terme, où l'«Admiration», la 1ère des 'passions' de l'âme, est cet 'étonnement devant la nouveauté radicale d'objets présentés par l'expérience') pareil dédoublement de répertoires 'tmp' cloisonnés l'un de l'autre dont le Système_UNIX paraît s'accommoder pour l'instant sans faire d'histoire.

♤​

Ce qui rend vraisemblable la suppression du : 'lien symbolique '⤻tmp'' à la racine de l'OS, c'est justement l'impossibilité, s'il y eût existé, de passer une commande 'sudo mkdir /tmp' de création d'un répertoire 'tmp' dans l'espace-racine, puisque, un lien-symbolique étant 'vu' comme identique à l'objet qu'il pointe, le Système rejetterait sans appel la création d'un objet-doublon au motif que : 'file exists' = l'objet existe déjà. Ce car 2 objets de même intitulé ne peuvent coexister dans le même espace sous le même rapport (selon le «Principe de Non-Contradiction», l'intitulé valant pour l'objet).

♧​

Une commande dans le «Terminal» :

ls -al /private

devrait produire en réponse un :

[COLOR="Red"]d[/COLOR]rwxrwxrwt   root  wheel   [COLOR="Red"]tmp[/COLOR]

assurant que le sous-répertoire 'tmp' est bien toujours présent dans /private en concurrence du néo_/tmp indûment créé à la racine de l'OS. Alors la solution serait de faire d'abord un :

sudo rm /tmp

et ↩︎ (retour-chariot = presser 'Entrée') + password (admin) + ↩︎ [= suppression du néo-répertoire 'tmp' à la racine). Puis de faire :

sudo ln -s /private/tmp /tmp

reconstituant le lien symbolique '⤻tmp' dans l'espace-racine de l'OS, où il pointe directement le sous-répertoire '/private/tmp'. En guise de vérification, un :

ls -al /

devrait produire un concluant :

[COLOR="Red"]l[/COLOR]rwxr-xr-x   root         wheel      [COLOR="Red"]tmp -> private/tmp[/COLOR]

La commande sudo n'ayant vraisemblablement produit qu'un root staff en guise d'accédants, rectifier le tir par un :

sudo chown 0:0 /tmp

rétablissant wheel comme groupe sur le lien symbolique, suivi, par acquis de conscience, d'un :

sudo chmod 755 /tmp

ne portant que sur le lien symbolique afin de le réserver en édition au seul root (mais, comme on l'a vu, cela n'empêche pas de le supprimer en renseignant un mot-de-passe admin).

Ce, afin de restaurer le Système_UNIX dans son architecture logique. Mais je ne commande personne, n'est-ce pas? puisque le problème est 'résolu'...

♡​