0 votes

Dossiers de l'accueil de Mac Big Sur autorisations : Système de fichiers en lecture seule lors du renommage de fichiers

MISE À JOUR #2

J'ai réussi à renommer les fichiers avec succès en utilisant sed:

for f in *.Rdat; do mv $f $(echo $f | sed "s/PCC-//"); done

MISE À JOUR J'ai découvert que je pouvais renommer des fichiers individuellement:

mv 'PCC-ASR-L.Rdat' 'ASR-L.Rdat'

Il semble donc que le problème survient uniquement lorsque j'essaie de renommer en lot dans une boucle for. Je voudrais toujours comprendre pourquoi.

MESSAGE ORIGINAL

Après la mise à niveau vers Big Sur depuis Catalina, j'ai essayé d'utiliser le terminal pour renommer certains fichiers dans un sous-dossier de mon dossier Home. J'avais créé et utilisé ce sous-dossier avant la mise à niveau. Plus précisément, j'ai essayé de renommer un groupe de fichiers Rdat en utilisant une boucle for bash. Je pouvais le faire sous Catalina, mais maintenant j'obtiens une erreur. Ici, j'essaie de remplacer 'PCC-' dans chaque nom de fichier par une chaîne vide (c'est-à-dire ''):

for f in *.Rdat; do mv $f ${f/PCC-//}; done

Cela génère une erreur pour chaque fichier, comme ceci (pour le fichier PCC-ASR-H.Rdat):

mv: /ASR-H.Rdat: Système de fichiers en lecture seule

Cela semble étrange car en tant que propriétaire du dossier, j'ai des permissions d'écriture:

drwxr-xr-x    8 mike  staff   256 Nov 21 15:04 Rdatafiles

Et j'ai des permissions d'écriture pour les fichiers du dossier (exemple):

-rw-rw-r--@ 1 mike  staff  10926 Dec  4 18:26 PCC-ASR-H.Rdat

J'ai essayé de désactiver SIP en Recovery Mode:

csrutil disable

Mais le problème persiste. Est-il possible de rendre des sous-dossiers du dossier Home inscriptibles sous Big Sur? Y a-t-il des changements supplémentaires que je dois apporter au système (c'est-à-dire des permissions) pour permettre l'accès en écriture? Ou est-ce que je dois maintenant déplacer mes fichiers de travail hors de Home et dans, par exemple, Home/Documents, pour éviter ce problème?

0 votes

Le problème est le double slash dans ${f/PCC-//}. Contrairement à un schéma de substitution sed, il n'y a pas de / à la fin du modèle de remplacement (il est terminé par }), donc le / supplémentaire est pris comme chaîne de remplacement. Cela transforme par exemple "PCC-ASR-L.Rdat" en "/ASR-L.Rdat", ce qui (en raison du "/") se trouve à la racine du système de fichiers... qui est en lecture seule. Remarque : l'utilisation de set -x avant la commande montrera ce qui se passe (c'est-à-dire à quoi ressemble la commande après l'exécution des substitutions) dans des cas comme celui-ci.

0 votes

Wow explication impressionnante @GordonDavisson! Si vous pouvez en faire une réponse, je la sélectionnerai comme correcte.

0 votes

Utilisez la fonction de renommage de Finder.

1voto

Gordon Davisson Points 30215

Le problème réside dans les doubles barres obliques dans ${f/PCC-//}. Contrairement à un schéma de substitution sed, il n'y a pas de / à la fin du motif de remplacement (il est terminé par }), donc la barre oblique supplémentaire est prise comme la chaîne de remplacement. Cela transforme par exemple "PCC-ASR-L.Rdat" en "/ASR-L.Rdat", ce qui (en raison de "/") se trouve à la racine du système de fichiers... qui est en lecture seule.

Lorsque je fais des choses comme des renommages en lot, je n'arrive également souvent pas à tout faire correctement du premier coup, donc j'ai tendance à exécuter un essai à blanc avec echo devant la commande mv (ou cp ou rm ou...) d'abord, pour voir ce qui va se passer avant de l'exécuter réellement. Je recommande également fortement d'utiliser mv -i ou mv -f, ainsi s'il y a un quelconque conflit de nommage, il ne remplacera pas silencieusement et de manière irréversible les fichiers. De plus, mettre des guillemets autour des références de variables est une bonne idée, au cas où des noms de fichiers contiendraient des caractères étranges.

Ainsi, mon essai à blanc ressemblerait à quelque chose comme ceci :

for f in *.Rdat; do echo mv -i "$f" "${f/PCC-/}"; done

...et si cela semblait correct, j'appuierais sur la flèche vers le haut pour le récupérer, supprimerais le "echo", et le relancerais pour de vrai.

Si vous avez besoin de dépanner encore plus en détail, utiliser set -x avant la commande montrera ce que le shell pense se passer (c'est-à-dire à quoi ressemble la commande après que les substitutions ont été effectuées) dans des cas comme celui-ci.

LesApples.com

LesApples est une communauté de Apple où vous pouvez résoudre vos problèmes et vos doutes. Vous pouvez consulter les questions des autres utilisateurs d'appareils Apple, poser vos propres questions ou résoudre celles des autres.

Powered by:

X