L’odierno
OS X è progettato
perché l’utente
medio di un Mac non debba affatto preoccuparsi (e occuparsi) del filesystem
sottostante a tutte le operazioni del sistema operativo. OS X gestisce tutto ciò che è legato alla gestione dei file sui
dischi, dal buon vecchio hard disk alle moderne unità SSD, e periodicamente esegue alcuni
script di manutenzione che mirano a garantirne il buon funzionamento. Se una
volta ci si preoccupava di deframmentare dischi, riparare permessi,
disabilitare estensioni e ricostruire Scrivanie, oggi questi retaggi del
passato sono scomparsi in favore di un sistema operativo che cerca il più possibile di auto-manutenersi.
Non
è un compito così semplice. Quando la più banale delle applicazioni si avvia e
comincia a lavorare, comincia anche a scrivere i propri dati sul disco e a
intervenire su altri file di supporto che possono essere o meno già presenti: database, librerie, plugin,
estensioni, file di preferenze, metadati, cache, file temporanei, anteprime
grafiche… tanti
file, a volte decine, che vengono modificati e aggiornati ogni volta che
eseguiamo operazioni apparentemente banali come lanciare iPhoto, editare un
file di testo oppure controllare la posta con Mail. È normale che ci sia tutta questa
continua attività in
un sistema operativo, ma perché tutto funzioni e sia verificabile (e soprattutto
riparabile) è importante
che le applicazioni la svolgano seguendo le raccomandazioni di Apple. Non è detto che sia sempre così e possono verificarsi casi in cui un
particolare file, magari secondario, non viene gestito correttamente – o più semplicemente si corrompe – e mette in crisi il funzionamento di
una particolare applicazione. In questi frangenti i tool tradizionali di
riparazione possono essere inutili, dato che si muovono per linee generali e
non possono conoscere i minimi dettagli del funzionamento di ogni singola
applicazione.
I
più smanettoni possono fare un passo in
più e mettere in campo fseventer, una
piccola utility di monitoraggio gratuita la cui funzione principale è darci una rappresentazione grafica di
ciò che sta accadendo al filesystem del
nostro Mac man mano che lavoriamo, in modo da comprendere meglio il
funzionamento di un’applicazione e magari di individuare quale file stia
creandole problemi. Non è detto che in questo modo si riesca a risolvere qualsiasi
difficoltà e
anzi bisogna muoversi con una notevole cautela, dato che intervenire
manualmente su file di cui in teoria non dovremmo occuparci potrebbe causare
problemi maggiori di quelli che stiamo cercando di risolvere. Può essere però un aiuto in più per le applicazioni che non
intervengono troppo intensamente sul filesystem e i cui eventuali file
“problematici” possono quindi essere individuati con una relativa
facilità.
L’albero dei file
Il
primo passo da fare è ovviamente procurarsi fseventer, che va scaricato dal sito
della software house neozelandese fernLightning (www.fernlightning.com).
Non facciamoci spaventare dal look “anni Novanta” del sito, fseventer
è comunque compatibile con OS X
Mavericks. Il software va installato sul disco principale del Mac, nella
configurazione standard di OS X sarà bloccato al primo lancio da Gatekeeper perché non proviene dai canali attualmente
considerati sicuri o certificati da Apple. Possiamo comunque lanciarlo con il
comando Apri del suo menu contestuale, a questo punto ci verrà chiesta la password di amministratore
perché il
software installa un suo modulo di monitoraggio degli eventi funzionalmente
autonomo dalla console di visualizzazione e questa installazione va autorizzata
esplicitamente. Fatto questo ci troviamo davanti a una finestra vuota con in
alto una toolbar che in qualche modo ricorda quella di un altro software di
monitoraggio noto agli utenti Mac: Console. Per avviare il controllo in tempo
reale del filesystem basta premere il pulsante Stop/Record, il primo da
sinistra.
A
questo punto l’area di visualizzazione della finestra comincia a popolarsi
con una struttura ad albero che replica quella del filesystem del Mac ma considerando
solo le cartelle e i file che vengono creati, cancellati o modificati in
qualche per contenuto, nome o attributi. La radice è quindi la root (/) del filesystem e
le foglie sono i singoli file, che appaiono in colore rosso se non esistono più,
quindi se sono stati cancellati o rinominati. Come si nota dalle schermate di
queste pagine, bastano pochi secondi di monitoraggio per riempire la
visualizzazione grafica dell’applicazione (qui risultano utili i
pulsantini di ingrandimento e riduzione in basso a destra).
Le
informazioni raccolte da fseventer sono diverse e la rappresentazione grafica
le riassume in maniera abbastanza efficace. Ad esempio, ogni cartello e ogni
file “foglia” che siano stati modificati più di una volta riportano un badge rosso
con il numero di operazioni che hanno subito, in modo da rendere immediatamente
visibili gli elementi del filesystem che sono gestiti con la maggiore frequenza
e quindi con tutta probabilità collegati a processi eseguiti costantemente in background,
come il “demone” che controlla le operazioni di backup in rete di
Retrospect. Nella rappresentazione grafica è possibile anche avere un colpo d’occhio
su ciò che
sta facendo una particolare applicazione, ad esempio proprio in figura 1 si può vedere una frazione del complesso
delle operazioni di salvataggio e modifica che Pages esegue mentre scriviamo un
documento localizzato su iCloud, salvandone versioni, miniature di anteprima e
metadati in locale (in Library: Mobile Documents) prima del caricamento nella
nuvola di Apple.
La
rappresentazione grafica mostra anche altri dettagli. Passando con il puntatore
del mouse su un file o su una cartella appare per qualche secondo un pop-up con
descritta sinteticamente la sua operazione di modifica più recente, quanto tempo fa è avvenuta e quale processo l’ha
generata. Facendo doppio clic su un file o una cartella li si apre in una
finestra del Finder, tranne che per quei percorsi che il Finder di default non
potrebbe visualizzare, come quelli all’interno della cartella Libreria.
Cliccando sul pulsante Info, il primo da sinistra nel blocco destro
della toolbar, si attiva una piccola finestra flottante ridimensionabile che
mostra tutta la sequenza degli eventi associati a un particolare file: sono gli
stessi tipi di informazioni mostrati nel pop-up che abbiamo appena descritto,
solo che la finestra non si limita all’evento più recente ma elenca tutti quelli
memorizzati da fseventer
Una vista diversa
La
vista grafica di fseventer è la più efficace perché raggruppa le modifiche apportate ai file proprio seguendo
la gerarchia del filesystem, il che permette di associare fra loro le modifiche
dello stesso tipo o della stessa applicazione, perché spesso (ma non esclusivamente) si
collocano in una medesima cartella. Questa visualizzazione diventa però rapidamente affollata di
informazioni, problema che si può affrontare con la funzione di filtro collegata al pulsante Filter.
Cliccandolo è possibile
definire una sequenza di condizioni basate su vari parametri, a partire dal
percorso di una particolare sezione del filesystem sino al processo che ha
generato la modifica, ma anche classificando gli eventi registrati in base al
loro tipo e suddividendoli tra quelli strettamente legati al filesystem o più ampiamente di sistema.
Chi
preferisce una visualizzazione meno d’effetto ma non per questo meno ricca
di informazioni può optare
per la vista tabellare, che si attiva cliccando sul pulsantino centrale del
“trio” immediatamente vicino al pulsante Stop/Record (il terzo
pulsantino, per la vista in timeline, non è ancora attivo). Nella vista tabellare abbiamo un elenco
sequenziale in ordine cronologico di tutti gli eventi registrati, con indicato
il percorso dell’elemento coinvolto, il momento in cui è avvenuto, il tipo di modifica, il
processo che l’ha causata e, per gli eventi di sistema, il suo EUID. Nella
vista tabellare si perde l’immediatezza di quella ad albero ma
sono visibili subito più informazioni e le colonne della tabella sono ordinabili,
quindi è ad
esempio possibile disporre gli eventi registrati in ordine di processo con un
semplice clic.
Nella
visualizzazione a tabella fseventer mette in sequenza gli eventi man mano che
si verificano, riempiendo velocemente schermate dopo schermate. Queste possono
essere cancellate con il pulsante Clear (l’effetto
è lo stesso anche per la
visualizzazione ad albero) ma per seguire il comportamento del sistema in
determinate circostanze diventa più utile il pulsante Flag, che inserisce un marcatore
vuoto nella sequenza degli eventi e permette così di individuare quelli che si sono
verificati prima e dopo di un certo momento, quello in cui abbiamo appunto
premuto Flag. Anche nella vista a tabella sono disponibili sia le funzioni di
filtro sia la finestra flottante di dettaglio, mentre non è più possibile fare doppio clic su un
percorso per farlo aprire in una finestra del Finder.
Per
ottimizzare il funzionamento di fseventer si usano, come accennato, le sue
preferenze. Qui si indica dopo quanto un evento va considerato
“scaduto” e quindi eliminato dalle visualizzazioni, il massimo numero
degli eventi memorizzabili (non oltre diecimila), quali modifiche al filesystem
tracciare e un paio di dettagli sulla visualizzazione grafica, di cui il più importante è se mantenere un unico albero con
tutto il filesystem o suddividerlo in alberi dedicati ciascuno a uno specifico
volume.
L’esempio
pratico
Come
conviene usare fseventer? Secondo noi in due modi, uno quasi
“didattico” e uno più orientato alla risoluzione di problemi. Il primo utilizza
fseventer per capire meglio le operazioni legate al filesystem che esegue un’applicazione
durante il suo funzionamento e quindi dove si trovano i file indispensabili
alla sua operatività. Un buon esempio può essere Mail: lanciamo fseventer e subito dopo Mail, magari
impostando subito un filtro di visualizzazione che mostri solo gli eventi
collegati all’applicazione per la posta elettronica. Così facendo si impara a conoscere la
struttura dati di Mail, con cartelle nome.mbox distinte per le varie mailbox di
ciascun account, un file info.plist per ciascuna mailbox e i singoli messaggi
salvati in cartelle dalle numerazioni apparentemente poco chiare. E in questo
modo vediamo poi che Mail va a scrivere anche in cartelle di sistema diverse
dalla sua propria (Users: nomeutente: Library: Mail: V2). Lo stesso può valere per iPhoto, nel cui caso
fseventer mostra l’impressionante sequenza di operazioni su disco legate alla
gestione della Libreria del software fotografico di Apple, come per qualsiasi
altra applicazione di rilievo, ad esempio per vedere come l’apertura
di un file in Pixelmator “muova” relativamente poco il filesystem.
Usare
fseventer per la risoluzione di problemi è meno immediato, nel senso che il tool ci permette di vedere
quali file e quali cartelle vengono modificati da un software ma non è in grado, di per sé,
di rilevare e segnalare malfunzionamenti. Lanciamo fseventer, passiamo alla
visualizzazione a tabella e poi avviamo l’applicazione per la quale registriamo
dei problemi, usandola qualche tempo per cercare di replicare l’avaria
che stiamo cercando di risolvere. Quando questa si verifica inseriamo subito un
marcatore con il pulsante Flag, meglio ancora (paradossalmente) se l’applicazione
si chiude da sola. A questo punto esaminiamo gli eventi registrati cercando di
individuare il file che l’applicazione stava elaborando
immediatamente prima dell’istante in cui si è chiusa (la chiusura di un’applicativo
è un evento registrato da fseventer e
associato al processo System) o in cui abbiamo inserito il nostro marcatore.
Quel file potrebbe essere la causa dell’errore, vale la pena esaminarlo – se possibile – oppure cercare su qualche forum
segnalazioni di malfunzionamenti legati a quel particolare documento o
cartella. Qualche informazione in più la si può recuperare da Console, incrociando le sue registrazioni con
quelle di fseventer.
