Ottieni mac tar per interrompere l'inserimento di ._ * nomi di file negli archivi tar [duplicato]


46

Possibile duplicato:
Perché ottengo file come ._foo nel mio tarball su OS X?

Creo script autoconf su un Mac. Quando tar viene eseguito, inserisce tutti questi ._ nomi foobar nell'archivio:

libewf-20110312/borlandc/builder5/ewfacquire/._ewfacquire.bpf
libewf-20110312/borlandc/builder5/ewfacquire/ewfacquire.bpf
libewf-20110312/borlandc/builder5/ewfacquire/._ewfacquire.bpr
libewf-20110312/borlandc/builder5/ewfacquire/ewfacquire.bpr

Ora quello che sta succedendo è che il filesystem HFS di Apple sta mettendo le proprietà del file nei nomi ._ foobar in modo che possano essere ripristinati su un altro sistema Mac. Ma non li voglio --- sono solo spazzatura per me. C'è un modo per sopprimerli?



2
@geekosaur L'utente su unix.SE ha rinunciato e ha accettato una risposta errata.
Daniel Beck

C'è anche una domanda correlata alla domanda SU sull'estrazione corretta dei ._*file dagli archivi (ad es. .__init__.py) Che utilizza la stessa soluzione.
Chris Johnsen,

Risposte:


69

Per una risposta a un'altra domanda , è possibile impostare la variabile di ambiente non documentata (?) COPYFILE_DISABLE per impedire a molti dei programmi forniti dal sistema (incluso tar ) di dare un significato speciale ai ._*membri dell'archivio. In particolare, impedirà loro di:

  • memorizzazione dei dati degli attributi estesi (inclusi i fork di risorse) nei ._*membri dell'archivio
    (ovvero non "inquinare" gli archivi creati su Mac OS X ma destinati ad essere utilizzati su altri sistemi), e

  • tentando di estrarre attributi o risorse estesi dai membri dell'archivio denominati come ._*
    (ovvero non interpretare erroneamente i ._*membri dell'archivio negli archivi da altri sistemi).

Il valore che usi per la variabile d'ambiente non è importante (può anche essere la stringa vuota). Valori come 0e falsenon riattivano la funzione. L'unica cosa che conta è se la variabile è impostata (devi "disinserirla" per riattivare la funzione).

È possibile utilizzare questa variabile su singoli comandi sfruttando l'abilità delle shell in stile Bourne ( sh , ksh , bash , zsh , ecc.) Di aggiungere un prefisso ai comandi con variabili d'ambiente aggiuntive.

COPYFILE_DISABLE=1 tar cf new.tar …

Se il problema si presenta più spesso, è possibile impostare ed esportare questa variabile in uno dei file di inizializzazione della shell.

# turn off special handling of ._* files in tar, etc.
COPYFILE_DISABLE=1; export COPYFILE_DISABLE

Quando è necessario, è quindi possibile annullare l'impostazione della variabile per i singoli comandi.

(unset COPYFILE_DISABLE; tar cf somefile.tar …)

Su questo sistema Mac OS X 10.6, i seguenti comandi sembrano conoscere COPYFILE_DISABLE:

  • /usr/bin/tar(un collegamento simbolico a bsdtar)
  • /usr/bin/bsdtar
  • /usr/bin/gnutar
  • /bin/pax

COPYFILE_DISABLE è nato in Mac OS X 10.5. Se devi supportare 10.4, ha COPY_EXTENDED_ATTRIBUTES_DISABLE che funziona allo stesso modo.


WOW. Proprio quello che stavo cercando. Grazie. I miei file autoconf saranno molto, molto più puliti.
vy32,

0

Non un esperto, ma un po 'googling ha trovato questo: http://www.ofzenandcomputing.com/zanswers/3422

e questo: http://hintsforums.macworld.com/archive/index.php/t-28703.html

Il secondo comando sembra che potrebbe essere incorporato in uno script ... potresti non essere in grado di impedire la creazione di file fork di risorse ma puoi eliminarli automaticamente in seguito.

modifica: avrei dovuto menzionare che potrebbe avere risultati negativi, utilizzare a proprio rischio.


1
Lo script rimuove le fork di risorse dai file sul disco locale. Di solito servono a uno scopo (come cambiare l'applicazione associata di un certo file), quindi questo dovrebbe venire con un grande avvertimento.
Daniel Beck

La sceneggiatura non mi aiuta. Rimuove i file dal disco, non dall'archivio tar. Si scopre che non ho i file di risorse sul mio disco. Ma vengono messi in archivio. E a differenza dei file zip, non puoi semplicemente rimuovere i file da un archivio tar.
vy32,

(bah, timeout) In realtà, è possibile se si utilizza praticamente qualsiasi altro tartranne quello libarchivebasato su BSD (questo include Mac OS X), ma potrebbe non essere affidabile; l'installazione di GNU tar è spesso una buona idea. (Tuttavia, è doloroso. Penso che sia necessario elencarli tutti e quindi passare quei nomi sulla riga di comando.) Inoltre, i fork di risorse sono tecnicamente su disco, ma su HFS + sono memorizzati in attributi estesi; i ._file sono il modo di OS X di archiviare le fork di risorse in luoghi che non supportano gli attributi estesi.
Geekosaur,

0

Puoi provare a compilare il tuo tar, o installarlo da Macports o Fink se disponibile (Homebrew non ce l'ha). Con un po 'di "fortuna" dovrebbe ignorare i metadati di OS X e saltare la creazione di quei file.


Gradirei una spiegazione per il downvote. Grazie.
Daniel Beck
Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.