Je lance fréquemment un script qui crée trois fichiers dans /tmp puis les déplace dans le répertoire de destination. J'étais perplexe devant les messages d'erreur:
mv: ./20170608-l.gpx : définir propriétaire/groupe (était : 503/0) : Opération non permise
mv: ./20170608-u.gpx : définir propriétaire/groupe (était : 503/0) : Opération non permise
mv: ./20170608.csv : définir propriétaire/groupe (était : 503/0) : Opération non permise
Le script n'utilise pas sudo, donc le groupe wheel (zéro) semblait étrange. En vérifiant /tmp (/private/tmp), j'ai vu que le bit collant était activé. Mais forcer le groupe à être wheel (ce que je m'attendais à ce qu'il fasse) n'est pas ce que dit Wikipedia (citante une page man de Leopard). Et m'empêcher de changer le groupe sur la copie non plus. La copie finit avec le même propriétaire—moi—et mon groupe—staff—donc en fait il a bien fait ce qu'il disait ne pas permettre.
Je peux comprendre la logique de ce que dit la page man, mais pourquoi le message d'erreur dit que quelque chose de différent n'était pas autorisé quand en fait c'est exactement ce qui s'est passé ? Et pourquoi les fichiers dans /tmp sont créés avec le groupe wheel alors que ce n'est pas ce que le bit collant est censé faire ?
/tmp est racine/wheel comme prévu,
WGroleau@MBP ~ % ls -latde@ /private/tmp
drwxrwxrwt 7 root wheel 224 Dec 21 09:58 /private/tmp
mais le document mentionné déclare que le bit collant empêche la suppression par quelqu'un d'autre que le propriétaire. Comme j'étais le propriétaire, cela n'a pas d'importance. Mais cela ne dit pas ce que je pensais qu'il voulait dire, à savoir annuler le groupe du créateur. Cependant, c'est bien ce qui s'est produit. Et ensuite le message d'erreur indique faussement qu'il n'a pas pu changer le groupe en le mien. Pas sûr si changer le groupe est requis quand la destination n'a pas de bit collant :
_WGroleau@MBP ~ % ls -late@d /Volumes/Sidecar/Sort_By_Date/2017/06/08 drwxrwxr-x 16 WGroleau staff 512 Dec 20 23:35 /Volumes/Sidecar/Sort_ByDate/2017/06/08