2013-06-05 14 views
7

Ho letto molti post sul blog e domande SO su UTI e su come OS X gestisce i tipi di file. Tuttavia, ci sono ancora alcune cose che non ottengo:Da dove viene l'UTI?

  • Come vengono create le UTI dal sistema per ciascun file? Come sviluppatore dichiaro passivamente un UTI per il mio tipo di file, ma il sistema è responsabile dell'assegnazione dell'UTI per ogni file corrispondente. La mia impressione attuale è che le UTI siano create al volo dal Finder in base all'estensione del file.

  • Dove sono archiviate UTI a livello di file system? Ho appreso che l'UTI può essere visualizzato con il comando mdls. Ciò implica che l'UTI è memorizzata lungo i metadati di Spotlight? Cosa succede se Spotlight è spento?

  • E 'corretto che non ci siano API per aggiungere o modificare manualmente un UTI per un file specifico?

+0

Hai letto la referenza Apple? https://developer.apple.com/library/mac/#documentation/FileManagement/Conceptual/understanding_utis/understand_utis_intro/understand_utis_intro.html –

+0

Naturalmente ho letto il riferimento. Ma spiega solo come sono strutturate le UTI e come dichiararle nella tua app. Quello che voglio sapere è come funzionano a livello di file system. Ho aggiornato la mia domanda per renderla un po 'più chiara. – codingFriend1

risposta

14

In realtà non c'è molta magia. Hai posto diverse domande, quindi cercherò di fornirti ognuna delle risposte:

Come vengono create le UTI dal sistema per ogni file?

Launch Services mantiene un database di tutte le applicazioni (e alcuni altri tipi di bundle) sul Mac e le informazioni rilevanti dichiarate nei propri file Info.plist. Aggiorna automaticamente queste informazioni: penso che un demone stia monitorando il file system per controllare le modifiche alle applicazioni, ma non conosco i dettagli. Che cosa sono do so è che è possibile chiedere uno strumento chiamato lsregister per scaricare l'intero database per voi. In Terminal su Mountain Lion:

$ /System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks/LaunchServices.framework/Versions/A/Support/lsregister -dump 

Le varie funzioni UTType anche accedere a questo database Launch Services (anche se non sono sicuro se lo fanno direttamente o se essi comunicano con una sorta di demone che fa per loro) .

Dove sono archiviate UTI a livello di file system?

Bene, l'attuale database di Servizi di avvio sembra essere posizionato in un punto diverso su ciascun Mac. Sulla mia, sembra essere a /private/var/folders/mf/1xd7vlw90dj5p4z1r5f800bc000101/C/com.apple.LaunchServices-0371025.csstore. (Almeno, lsregister tiene aperto questo file mentre funziona, non sono sicuro di cosa ci sia dentro, ma presumo sia il database.)

Questo è solo un elenco degli UTI dichiarati, però. Non esiste un campo UTI collegato a un determinato file. Quando chiedi a Cocoa l'UTI di un file, ad esempio, -[NSWorkspace typeOfFile:error:] o -[NSURL getResourceValue:forKey:error:], in realtà estrae l'estensione del percorso dal nome del file e quindi chiama UTTypeCreatePreferredIdentifierForTag() per recuperare l'UTI pertinente. (È un po 'più complicato di così, perché guarda anche a cose come se il percorso porta a una directory o un file di dispositivo o qualcosa del genere, ma questa è l'idea di base.)

Ciò implica che l'UTI è memorizzato lungo i metadati di Spotlight? Cosa succede se Spotlight è spento?

Spotlight fa mantiene UTI di file nel suo database, ma è solo così può rapidamente cercare e filtrare per tipo.Come ogni altra cosa nell'indice di Spotlight, questa informazione non è canonica; è solo usato per cercare rapidamente i dati che sono effettivamente memorizzati altrove. Se spegni Spotlight, va bene, nient'altro dipende da questo.

E 'corretto che non ci siano API per aggiungere o modificare manualmente un UTI per un file specifico?

Sì, perché l'UTI viene calcolato in fase di esecuzione da altre informazioni sul file. Cambiare l'UTI di un file ha tanto senso quanto modificare la lunghezza del suo nome: non puoi farlo senza cambiare il nome stesso.

+0

Grazie! Questo è tutto ciò che volevo sapere. – codingFriend1