Salut
jeanaz
je suis sous maverick et je n'ai pas accès à "couper" lorsque je suis dans mon disque dur externe. jusqu'ici ça ne me posais pas de problème car en ouvrant deux fenêtres finder je pouvais déplacer un fichier dans un autre endroit du disque. mais maintenant il copie obligatoirement, et je n'ai pas l'espace nécessaire pour copier/coller/supprimer !
comment déplacer ?
Ton problème intrigue mon esprit
farfelu, càd. ami de la
conjecture_aventureuse. Alors en voici un échantillon
☞
♖
J'assume que, étant donné un espace propriétaire homogène d'utilisateur (tel celui du volume de ton DDE approprié en droit à toi-même
jeanaz), le 'déplacement_au_pointeur' d'un
item d'un 'lieu' à un autre 'lieu' inclus dans cet espace (comme d'un fichier_x = 'objet' d'un dossier_A = 'source' à un dossier_B = 'destination') équivaut, en mode
graphique à l'invocation ('call') d'un programme UNIX : le binaire
mv localisé à l'adresse :
/bin.
J'assume, en mode dérivé, que lorsque l'invocation de
/bin/mv n'a pas valeur de 'renommer_l'objet' (lequel ne change pas de localisation), mais de 'déplacer_l'objet' (lequel garde son nom mais change de lieu de résidence), alors
mv invoque à son tour successivement 2 autres
binaires UNIX localisés eux aussi dans
/bin : en 1ère instance
cp (qui équivaut à : 'copier' l'objet à la 'destination' pointée), et, en deuxième instance relayant la première,
rm (qui équivaut à : 'supprimer' l'objet de la 'source').
♢
Conjecturalement, donc, si ton 'déplacer_au_pointeur' échoue à [copier_à_destination + supprimer_de_la_source] (du fait que le binaire
mv qu'il invoque graphiquement ne parvient pas à sous-invoquer successivement
cp +
rm), mais seulement à [copier_à_destination] (par l'invocation réussie du binaire
cp) ; alors se pourrait-il que le binaire
rm (dédié à la suppression d'objet d'une source et censé compléter en succession l'opération préalable de
cp dans l'invocation de
mv) ait un problème de droits d'exécution?
Rien de plus simple dans le «
Terminal» que de demander un :
dont le résultat devrait être régulièrement :
Bloc de code:
-rwxr-xr-x root wheel /bin/rm
en parfaite symétrie, si l'on demande :
avec la réponse :
Bloc de code:
-rwxr-xr-x root wheel /bin/cp
et, si l'on demande :
avec la réponse :
Bloc de code:
-rwxr-xr-x root wheel /bin/mv
De toute nécessité, chacun des 3
binaires doit supporter l'
executive_bit ('
x') à tous les échelons d'
accédants, y compris le
everyone ; comme il doit supporter le
readable_bit ('
r') à tous les échelons d'
accédants, y compris encore le
everyone.
♤
Au cas où le statut de droits des 3
binaires est régulier, alors il se pourrait que l'
initiateur de leur invocation (en mode graphique, bien sûr), càd. toi-même
jeanaz n'ait pas les
permissions suffisantes de les faire s'exécuter dans l'espace pointé = celui de ton DDE. Rien de plus simple à vérifier --> ton DDE connecté, dans le «
Terminal» demande :
et normalement il faudrait que tu obtiennes en réponse, relativement au sous-volume
Sans Titre de
Volumes :
Bloc de code:
drwxrwxr-x jeanaz staff Sans Titre
càd. des permissions révélant la présence du
writable_bit ('
w') à tous les échelons d'
accédants mais d'abord toi-même qui doit être listé en propriétaire de l'espace du volume, habilité donc à affecter l'existence des objets résidents dans ses lieux.
Si tout est conforme aux attentes, quels que soient les droits intrinsèques des
objets présents dans cet espace (droits portant sur le sub_espace d'écriture qu'ils recèlent), un droit d'
écriture à l'espace du répertoire qui les inclut (ici le volume
Sans Titre) suffit normalement à permettre leur
suppression, càd. l'exécution du
binaire rm à leur emplacement local.
♧
Se pourrait-il alors que
Sans Titre soit
partitionné, et que la manœuvre graphique au pointeur invoque un déplacement de
volume_A à
volume_B? Alors la conjecture subalterne serait que, les droits sur
volume_B étant :
Bloc de code:
drwxrwxr-x jeanaz staff volume_B
les droits sur
volume_A seraient par contre :
Bloc de code:
dr[COLOR="Red"]-[/COLOR]xr[COLOR="Red"]-[/COLOR]xr-x jeanaz staff volume_A
càd. que le propriétaire (= toi-même) serait dépourvu de la
permission d'
écriture à l'espace du
volume_A, ce qui logiquement lui donne
permission de
copie (càd. d'invoquer avec succès le
binaire cp), mais ne lui donne pas
permission de
suppression de la source de la
copie (càd. d'invoquer avec succès le
binaire rm sur cet espace).
Une simple demande :
Bloc de code:
ls -l /Volumes/"Sans Titre"
suffirait à vérifier ou infirmer cette conjecture, en répondant soit :
Bloc de code:
dr[COLOR="Red"]-[/COLOR]xr[COLOR="Red"]-[/COLOR]xr-x jeanaz staff volume_A
drwxrwxr-x jeanaz staff volume_B
auquel cas elle serait
vérifiée ; soit :
Bloc de code:
dr[COLOR="Red"]w[/COLOR]xr[COLOR="Red"]w[/COLOR]xr-x jeanaz staff volume_A
drwxrwxr-x jeanaz staff volume_B
auquel cas elle serait
infirmée - puisque le propriétaire
jeanaz aurait la
permission d'
écrire au sub_espace du
volume_A, càd. d'invoquer avec succès (en mode graphique) le
binaire rm impliqué à la suite de
cp dans la commande globale
mv.
♡
Alors le
farfelu de service (= celui qui s'invoque sous l'avatar de
macomaniac ) aurait erré conjecturalement et le mystère demeurerait entier.
♔
