I file ZIP conservano tutte le funzionalità di HFS +, se creati utilizzando il comando Comprimi di Finder?

Naviga le tue risposte
0

È una buona idea fare il backup di una directory su un filesystem HFS + usando la funzione di compressione del Finder e quindi copiare il file ZIP su un disco fisso FAT32, su Dropbox, ecc.? O potrebbe causare danni ai dati o perdita di dati?

Ad esempio, se comprimo la mia libreria di iTunes e i collegamenti simbolici sono sostituiti da un'altra copia del file, si tratta di una modifica della semantica. Se il mio disco rigido si blocca e ripristino una copia della libreria di iTunes dal backup, iTunes potrebbe non funzionare correttamente a causa di ciò. Ad esempio, la modifica del contenuto di un file non influisce sull'altro. Cancellare il file puntato significa che non puoi più leggere il contenuto di quel file tramite il link simbolico, che è diverso se il link simbolico è sostituito da una copia di quel file. iTunes potrebbe arrestarsi in modo anomalo a causa di una libreria corrotta o di danneggiare ulteriormente la libreria, il che significa che il backup non è servito allo scopo.

È garantito che tutte le directory valide comprimino su ZIP senza errori e si espandano su una copia identica della directory originale, senza alcuna perdita di informazioni o modifiche semantiche? In particolare, i file ZIP supportano tutte le funzionalità di HFS +?

  1. link simbolici
  2. Collegamenti hard (comprese le directory supportate su HFS +)
  3. Alias
  4. Attributi estesi
  5. fork delle risorse
  6. ACL
  7. Autorizzazioni Unix
  8. Tutti i nomi di percorso validi in HFS +. In altre parole, ZIP supporta tutti i caratteri validi per l'uso nel nome di un percorso? ZIP supporta il nome di percorso più lungo che è possibile creare in HFS +, oppure esiste un limite di lunghezza del percorso inferiore nel formato ZIP?
  9. C'è un limite di dimensioni del file di 4 GB?

... e così via.

Sono preoccupato per il potenziale di modifiche silenziose, che causano la perdita o la corruzione silenziosa dei dati senza che io ne sia a conoscenza finché non è troppo tardi.

Questa è una domanda sul formato ZIP e anche sul comando Comprimi del Finder. Perché anche se il formato ZIP supporta qualcosa, se l'implementazione del Finder no, non aiuta.

    
posta Vaddadi Kartick 13.08.2014 - 09:08
fonte

1 risposta

1

Nessun credito per me. L'ho preso letteralmente dall'utente NSGod : link

La mia aggiunta, un po 'ovvia:

  • il filesystem di destinazione dovrebbe supportare symlink, collegamenti fissi, ecc, altrimenti non funzionerà
  • puoi usare il comando zip nella riga di comando e conservare questi tipi di file manualmente con zip --symlinks -r foo.zip foo/

Come stai creando l'archivio .zip in OS X? (Utilizzando uno strumento da riga di comando, e in tal caso, quale, o usando Archive Utility, ecc.)

Quale sistema operativo è il computer di destinazione (in cui verrà decompresso l'archivio) e quale metodo stai usando per decomprimere il file?

Prima di tutto, in OS X, i link simbolici sono in pratica semplici file di testo con alcune informazioni extra "Mac" che consentono a OS X di considerare il file come un collegamento simbolico. Queste informazioni extra sul Mac sono un tipo di file speciale, codice del creatore e informazioni sul flag del Finder, che non sono memorizzate nel file stesso, ma nella directory del disco HFS +.

In OS X, quando si crea un file .zip, non c'è spazio nel flusso zip per queste informazioni extra sul Mac, quindi, in un certo senso, il collegamento simbolico viene memorizzato all'interno del file zip come un semplice file. Se qualcuno su un altro Mac può decomprimere l'archivio e farlo rappresentare correttamente, la struttura originale sembra dipendere da chi o cosa si usa per decomprimerlo.

Ad esempio, circa un mese fa una società pubblicò un gioco su Steam, il software di distribuzione di giochi di Valve. Il pacchetto dell'applicazione di gioco includeva la libreria Cg di NVIDIA sotto forma di un framework, che utilizza internamente collegamenti simbolici. Originariamente c'era un problema con Steam che non ripristina correttamente le informazioni necessarie sul Mac su Trine.app come menzionato in questa discussione: link

L'immagine sotto mostra 2 diverse copie di Cg.framework, una che avevo installato separatamente dal sito web di NVIDIA (immagine in alto), e l'immagine in basso mostra ciò che è stato ricevuto con il gioco:

Sinotichetuttiglielementicorrispondono,maquellichedovrebberoesserecollegamentisimbolicisonosemplicifiledidati.

Dopoaverdatoun'occhiatapiùdavicinoalrecordFSCatalogInfoperentrambiglielementi,mièstatochiaroqualefosseilproblema:

Nell'immagine in alto noterai che l'inizio della struttura finderInfo ha i seguenti valori: 

0x736C6E6B = 'slnk'
0x72686170 = 'rhap'

Questi valori sono definiti in /usr/include/hfs/hfs_format.h: 

/*
 *  File type and creator for symbolic links
*/
enum {
    kSymLinkFileType  = 0x736C6E6B, /* 'slnk' */
    kSymLinkCreator   = 0x72686170  /* 'rhap' */
};

Il valore del 9 ° byte, 0x80, corrisponde al flag kIsAlias di finderInfo.finderFlags . Tale valore è definito in /System/Library/Frameworks/CoreServices.framework /.../ CarbonCore.framework /.../ Headers / Finder.h: 

enum {
    kIsAlias                      = 0x8000 /* Files only */
};

Sembra che la funzionalità di decompressione incorporata in OS X (Archive Utility) sia codificata per cercare i possibili file nell'archivio che sono stati decompressi che rappresentano collegamenti simbolici e per impostare le informazioni in modo appropriato. Credo che /usr/bin/ditto (se usato per la sua capacità di archiviare i file) si prende cura di questo anche per te. Non sono sicuro se zip o unzip faccia.

    
risposta data 13.08.2014 - 09:42
fonte

Leggi altre domande sui tag

2012 MacBook Air ha un punto di usura in basso a sinistra Segnalazione errori Apple improvvisamente disattivata. OSX 10.9.4