MacOS: riappare gli attributi estesi

Question

MacOS: riappare gli attributi estesi

#1 da (4 voti)

3

Alcuni file sul mio disco esterno sono visualizzati in grigio. Quindi, ho rimosso tutti gli attributi estesi usando il comando xattr -rc che riesce con successo e tutti i miei file appaiono normali. Tuttavia, dopo aver scollegato e ricollegato l'unità esterna, lo stesso set di file appare nuovamente grigio. Quindi, per copiare qualsiasi file, ho dovuto eseguire nuovamente il comando xattr per i file ogni volta che li fa comportare come normali file.

Per favore aiutami, non sono in grado di trovare la risposta per lo stesso dopo aver attraversato in modo approfondito il web e StackOverflow

Aggiornamenti

Tipi di file

Tutti i tipi di file come .dmg, .epub, .docx, ecc sono apparsi in grigio e non esiste un tipo specifico di file.

Per quanto riguarda gli attributi estesi

Quando rimuovo completamente tutti gli attributi estesi il problema scompare. Quindi, non sono a conoscenza di quale particolare attributo stia causando la disattivazione dei file.

Ecco l'output di ls leO@ su tali file in grigio.

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

-rwxr-xr-x@ 1 username  staff  -      3659 Jul  9 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 Jul  9 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

Formato dell'unità esterna

NTFS (scrivibile inizialmente tramite il software Mounty, ora nativamente usando alcuni comandi )

Aggiornamento 2

Ecco l'output di 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 00 | ................ | 00000020

macos terminal

posta geeksal 09.07.2018 - 19:39

fonte

1 risposta

Leggi altre domande sui tag macos terminal

Dove acquistare il pastello Logitech per uso didattico sull'iPad? AppleScript - Come identificare i pulsanti e premerli?

score 4 · Accepted Answer

La causa del problema, o piuttosto la causa dei sintomi del problema, è in effetti spiegata apprendendo il contenuto dell'attributo esteso com.apple.FinderInfo . Rivela che il Finder ha impostato rispettivamente il tipo di file e il creatore del file su brok e MACS , a indicare che il file è impegnato nel processo di copia e pertanto non è possibile accedervi. (Questi flag dovrebbero essere cancellati al completamento del processo di copia.) Di conseguenza, il Finder "spiazza" le icone di tali file per riflettere il loro stato di immutabilità da parte dell'utente. Cancellare l'attributo esteso com.apple.FinderInfo allevia la situazione rimuovendo la causa prossima.

Il vero problema, tuttavia, è la costante riassegnazione di questo stato "occupato in copia" ai vari file. In effetti, hai chiesto esplicitamente perché gli attributi estesi riappaiono per determinati file. La mia risposta: non conosco la meccanica degli eventi, ma so cosa c'è dietro.

Apple supporta nativamente la lettura, ma non la scrittura, su unità NTFS. Il metodo personalizzato di fstab che stai utilizzando per consentire la scrittura sul disco è noto per essere instabile e garantisce problemi. (Il tuo nome utente è veramente username ?) Mi sono chiesto come sei arrivato all'idea abusiva di cancellare gli attributi estesi per correggere la situazione inaccessibile dei file e una visita al sito del software Mounty (la fonte del tuo soluzione precedente) mi ha mostrato che era la loro raccomandazione specifica. Come hai imparato, non è una soluzione duratura. Il problema continuerà finché continuerai a utilizzare il tuo attuale metodo di accesso al filesystem NTFS.

Se è necessario disporre dell'accesso in lettura / scrittura a un'unità formattata NTFS e non è possibile sostituirlo con uno nel formato exFAT supportato nativamente, sarà necessario scegliere un'offerta di terze parti per fornire una soluzione permanente. Quelli che conosco quali offrono un'usabilità accettabile sono Tuxera, Paragon e Fuse / NTFS3G. I primi due sono prodotti commerciali disponibili a titolo gratuito; il terzo è una combinazione di due prodotti open source.

EDIT: Response to OP's comment below

Mi dispiace dire che non ho istruzioni da riga di comando che ti aiutino sicuramente. Credo che l'unico modo per risolvere il problema sia cambiare il metodo che usi per l'accesso al filesystem da uno che è noto per avere problemi, come il tuo metodo attuale, a uno che non lo fa.

Detto questo, offro il seguente puro esperimento, in quanto non ho modo di testarlo. Sappiamo che il vantaggio di cancellare gli attributi estesi dei file interessati dura solo fino al successivo montaggio dell'unità. È possibile che l'assegnazione di un valore fittizio all'attributo com.apple.FinderInfo di un file consentirà di mantenerla non sottoposta a controllo tramite il processo di montaggio e impedire al Finder di riassegnare lo stato di brok/MACS . In particolare, questo comando darà un tipo di file fasullo di hack a <targetfile.ext> . Provalo solo su uno o due dei tuoi file problematici e guarda cosa succede loro quando l'unità è smontata / rimontata.

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

(Perché tutti gli zeri? L'attributo esteso com.apple.FinderInfo deve essere scritto come un singolo blocco da 32 byte. Comunque, qualunque cosa possa sembrare qui, è un comando, tutto su una riga come ci si aspetterebbe.)