Question:
Les attributs étendus réapparaissent lors de la reconnexion du lecteur externe
geeksal
2018-07-09 22:39:02 UTC
view on stackexchange narkive permalink

Certains fichiers de mon lecteur externe sont apparus en gris. Par conséquent, j'ai supprimé tous les attributs étendus en utilisant la commande xattr -rc qui fait l'affaire avec succès et tous mes fichiers semblent normaux. Cependant, après avoir débranché et rebranché mon disque dur externe, le même ensemble de fichiers apparaît à nouveau en gris. Donc, pour copier n'importe quel fichier, j'ai dû réexécuter la commande xattr pour les fichiers à chaque fois, ce qui les fait se comporter comme des fichiers normaux.

Types de fichiers

Tous les types de fichiers tels que .dmg, .epub, .docx, etc. sont apparus grisés, il n'y a pas de type de fichier spécifique en tant que tel.

Ren ce qui concerne les attributs étendus

Lorsque je supprime complètement tous les attributs étendus, le problème disparaît. Par conséquent, je ne sais pas quel est l'attribut particulier qui fait que les fichiers sont grisés.

Voici la sortie de ls leO @ sur ces fichiers grisés. 

  -rwxr-xr-x @ 1 username staff - 4433605 9 juillet 22:38 xyz.dmg
    com.apple.FinderInfo 32
    com.apple.metadata: kMDItemWhereFroms 110
    com.apple.quarantine

-rwxr-xr-x @ 1 nom d'utilisateur personnel - 3659 9 juillet 22:38 replug_facetime.zip
    com.apple.FinderInfo 32
    com.apple.metadata: kMDItemWhereFroms 115
    com.apple.quarantine 58

-rwxr-xr-x @ 1 username staff - 22617886 9 juillet 22:38 robo3t-1.1.1-darwin-x86_64-c93c6b0.dmg
    com.apple.FinderInfo 32
    com.apple.diskimages.fsck 20
    com.apple.diskimages.recentcksum 80
    com.apple.metadata: kMDItemWhereFroms 161
    com.apple.quarantine 58

Format du lecteur externe

NTFS; inscriptible initialement via Mounty Software, maintenant en natif en utilisant certaines commandes.

Voici la sortie de xattr -pl com.apple.FinderInfo atom-mac.zip 

  com.apple.FinderInfo:
 00000000 62 72 6F 6B 4D 41 43 53 00 00 00 00 00 00 00 00 | brokMACS ........ |
00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ |
 00000020
@GordonDavisson J'ai mis à jour la question.Si vous êtes modérateur, pouvez-vous migrer la question vers AskDifferent si cela semble approprié.J'ai publié la question ici en raison d'une [question connexe] [1] déjà existante sur ce site [1]: https://stackoverflow.com/questions/4833052/how-do-i-remove-the-extended-attributes-on-a-file-in-mac-os-x?rq=1
Je n'ai pas ce privilège, mais je l'ai signalé à quelqu'un qui en a.En ce qui concerne la question elle-même, je ne peux pas le dire avec certitude, mais mon argent est là pour un bogue dans le logiciel Mounty que vous utilisez pour obtenir un accès en écriture à NTFS.
Il peut être utile de connaître le contenu de l'attribut FinderInfo pour quelques-uns de ces fauteurs de troubles.Si vous le souhaitez, veuillez modifier votre question pour ajouter les résultats de la commande suivante sur deux ou trois fichiers grisés: `xattr -pl com.apple.FinderInfo `
@DocG.J'ai mis à jour la question pour inclure la sortie de la commande `xattr -pl`.Veuillez vérifier et répondre.
@cjk: Les fichiers de l'exemple de sortie, plus ceux répertoriés sous l'en-tête "Types de fichiers", sont soit eux-mêmes des fichiers compressés, soit contiennent généralement des fichiers compressés quelque part dans leurs ensembles.
Deux réponses:
Doc G.
2018-07-23 04:08:36 UTC
view on stackexchange narkive permalink

La cause du problème - ou plutôt la cause des symptômes du problème - est en effet expliquée par l'apprentissage du contenu de l'attribut étendu com.apple.FinderInfo . Il révèle que le Finder a défini le type de fichier et le créateur du fichier respectivement sur brok et MACS, ce qui signifie que le fichier est engagé dans le processus de copie et n'est donc pas accessible. (Ces indicateurs sont censés être effacés à la fin du processus de copie.) En conséquence, le Finder «grise» les icônes de ces fichiers pour refléter leur statut d'immuabilité par l'utilisateur. L'effacement de l'attribut étendu com.apple.FinderInfo soulage la situation en supprimant la cause immédiate.

Le vrai problème, cependant, est la réaffectation constante de ce statut "occupé en cours de copie" aux différents fichiers. En effet, vous avez spécifiquement demandé pourquoi les attributs étendus réapparaissent pour des fichiers particuliers. Ma réponse: je ne connais pas les mécanismes des événements, mais je sais ce qu’il y a derrière.

Apple prend en charge nativement la lecture, mais pas l'écriture, sur les lecteurs NTFS. La méthode de contournement fstab sur mesure que vous utilisez actuellement pour autoriser l'écriture sur le disque est connue pour être instable et risque de causer des problèmes. (Votre nom d'utilisateur est-il vraiment nom d'utilisateur ?) Je me suis demandé comment vous en êtes venu à l'idée abstruse d'effacer les attributs étendus pour corriger la situation de fichier inaccessible, et une visite sur le site Mounty Software (la source de votre solution de contournement précédente) m'a montré que c'était leur recommandation spécifique. Comme vous l'avez appris, ce n'est pas une solution durable. Le problème continuera tant que vous continuerez à utiliser votre méthode actuelle d'accès au système de fichiers NTFS.

Si vous devez avoir un accès en lecture / écriture à un lecteur au format NTFS - et que vous ne pouvez pas le remplacer par un autre au format exFAT pris en charge nativement - vous devrez choisir une offre tierce pour fournir une solution permanente. Ceux que je connais qui offrent une utilisabilité acceptable sont Tuxera, Paragon et Fuse / NTFS3G. Les deux premiers sont des produits commerciaux disponibles sur une base d'essai gratuit; le troisième est une combinaison de deux produits open source.

EDIT: Réponse au commentaire d'OP ci-dessous

Je suis désolé de dire que je n'ai pas d'instructions de ligne de commande qui pourraient certainement vous aider. Je pense que la seule façon de résoudre le problème est de changer la méthode que vous utilisez pour l'accès au système de fichiers d'une méthode connue pour avoir des problèmes, comme votre méthode actuelle, à une autre qui n'en a pas.

Cela dit, je propose ce qui suit à titre purement expérimental, car je n'ai aucun moyen de le tester. Nous savons que l'avantage d'effacer les attributs étendus des fichiers affectés ne dure que jusqu'au prochain montage du lecteur. Il est possible que l'attribution d'une valeur factice à l'attribut com.apple.FinderInfo d'un fichier lui permette de persister sans encombre tout au long du processus de montage et empêche le Finder de réattribuer brok / MACS . Plus précisément, cette commande donnera un faux type de fichier de hack à <targetfile.ext> . Testez-le sur seulement un ou deux de vos fichiers problématiques, et voyez ce qui leur arrive lorsque le lecteur est démonté / remonté.

xattr -wx com.apple.FinderInfo 6861636B00000000000000000000000000000000000000000000000000000000 <targetfile.ext>

(Pourquoi tous les zéros? L'attribut étendu com.apple.FinderInfo doit être écrit comme un seul bloc de 32 octets. Quoi qu'il en soit, quoi qu'il ressemble ici, c'est une commande, tout une ligne comme vous vous y attendez.)

Je pense que tu as le problème.C'est génial.Puis-je atténuer d'une manière ou d'une autre par des commandes de terminal ou quelque chose ????Sauf pour tout logiciel commercial.Mon nom d'utilisateur n'est pas * nom d'utilisateur *, c'est juste par exemple.Auparavant, j'utilisais Mounty et cela posait des problèmes, je suis donc passé à la méthode fstab.Les logiciels que vous avez listés me sont déjà connus.J'espère que vous pourrez trouver un moyen par Mac, Linux ou Windows d'atténuer ce comportement.J'utilise tous les trois donc j'ai besoin de NTFS car c'est un bon système de fichiers.
+1 pour votre hack.Cela fonctionne mais j'ai quand même un problème avec l'un des fichiers.Voici la sortie de `xattr -pl com.apple.FinderInfo` pour ce fichier` 00000000 68 61 63 6B 00 00 00 00 00 00 00 00 00 00 00 00 | hack ............| 00000010 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 | ................ | 00000020` Pouvez-vous comprendre quel est le problème avec cela ??Votre hack ne fonctionne pas ici.Si vous résolvez ce problème, je marquerai certainement votre réponse comme acceptée.
Je ne vois rien dans ce qui précède, à l'exception du changement que j'ai suggéré.Si le fichier est toujours grisé, mon expérience a échoué et je m'excuse d'avoir perdu votre temps.
Hé, tu n'as pas besoin de t'excuser.Même si l'un des types de mes fichiers est toujours grisé, je le rechercherai et le trouverai moi-même ou je prendrai l'aide des gars qui savent vraiment ce qui se passe.Au fait, vous m'avez fait gagner beaucoup de temps.Soyez heureux ;)
Je vous remercie.N'oubliez pas que depuis que la nature du problème a changé, vous pouvez poser une nouvelle question décrivant quel type de fichier est toujours affecté, quels types ont été corrigés et toute autre information nouvelle.
J'ai eu exactement le même problème, j'ai donc installé Paragon pour macOS qui est disponible gratuitement sur [le site Web de Seagate] (https://www.seagate.com/gb/en/support/downloads/item/ntfs-driver-for-mac-os-master-dl /).J'ai parcouru le processus d'installation, redémarré et une fois que Paragon a monté le volume en tant que `r / w`, j'ai exécuté` xattr -rc / Volumes / `.J'ai ensuite effectué une réparation à l'aide de l'interface utilisateur de Paragon, démonté le lecteur, l'ai remonté et, à ma grande surprise, je n'ai plus été accueilli par une mer grise fichiers gris inaccessibles.
Terminator.J
2020-03-16 02:09:59 UTC
view on stackexchange narkive permalink

Je me rends compte que c'est une réponse partielle, mais réfléchir et l'écrire pourrait nous aider à trouver la réponse en nous basant sur une expérience supplémentaire avec ce problème.

Bien que oui, le pilote du système de fichiers NTFS intégré peut être répertorié comme instable, celui exFAT devrait être mature; J'ai utilisé exFAT pendant des années dans la production d'événements en direct pour pouvoir transférer des decks PowerPoint et du contenu audio / vidéo pour la lecture entre les systèmes Windows Mac &. Cela fonctionnait toujours plus ou moins bien.

Et pourtant, ce matin encore, le Finder de Catalina 10.15.3 n'a pas réussi à effacer l'attribut étendu brokMACS après avoir copié sur un lecteur au format exFAT en bon état. Blâmer Mounty pour avoir fourni une meilleure solution (en utilisant une interface graphique pour utiliser le pilote de système de fichiers intégré fourni par la première partie, au lieu d'avoir à installer des pilotes tiers supplémentaires, DEVRAIT être considéré comme meilleur) lorsqu'il s'agit de monter en lecture / écriture NTFS ignore le vrai problème; le Finder NOW ne parvient pas à effacer les attributs étendus temporaires sur plus d'un pilote de système de fichiers, alors qu'il ne se comportait pas de cette façon sur le type de système de fichiers.

L'utilisation des commandes cp depuis le terminal semble éviter le problème, mais cela ne résout pas le Finder.



ⓘ
Ce Q&R a été automatiquement traduit de la langue anglaise.Le contenu original est disponible sur stackexchange, que nous remercions pour la licence cc by-sa 4.0 sous laquelle il est distribué.
Loading...