Nella letteratura informatica quello dei filesystem è un argomento particolarmente caro, ampiamente trattato e sul quale la ricerca non manca; anzi. D’altra parte è anche prevedibile, considerata la loro importanza: è questo “pezzo di codice” a cui affidiamo i nostri dati (a cui ovviamente teniamo).
Si parla spesso di prestazioni, di ottimizzazione dello spazio occupato, di deframmentazione di file e cartelle, ma molto raramente viene affrontato l’argomento del case per i nomi.
Sì, perché esistono fondamentalmente due “scuole di pensiero”: quella che li vorrebbe insensitive (non c’è differenza fra maiuscole e minuscole nei nomi) e l’opposta che parteggia per il case sensitive. Da anni sembra scontato che quest’ultima sia LA strada da seguire, ma siamo veramente sicuri che debba esser così?
Innazitutto è da premettere che esiste un’altra qualità che un filesystem può avere: essere case preserving, ossia mantenere il case delle lettere che compongono il nome del file (o della cartella; più avanti parlerò solo di file, intendendo sempre entrambi gli oggetti).
Quindi se scrivo “Pippo.Txt” il filesystem non ne altererà il case, mentre uno come il FAT12, che non rispetta il case preserving, memorizzerà e restituirà sempre “PIPPO.TXT“. Ovviamente un filesystem case sensitive è anche case preserving, mentre uno insensitive può esserlo oppure no.
Prima di continuare a parlare di case, però, penso sia necessario aprire una necessaria parentesi per capire meglio il senso della domanda che è all’origine del titolo dell’articolo.
Sappiamo che un filesystem ha il compito di conservare le informazioni che gli sottoponiamo. Come sono strutturate queste informazioni? Le informazioni fondamentali che le caratterizzano sono sicuramente due: i dati (o contenuto) veri e propri e il nome che gli abbiamo associato.
Tralasciamo per il momento altri metadati, come la dimensione del file, la posizione del medesimo all’interno dell’albero del filesystem, numero e blocchi allocati, inode, ecc. ecc., perché non sono funzionali all’argomento in discussione.
Come utente, quindi, ho la necessità di conservare dei dati, e dargli un nome. Nome che dovrebbe fornire sufficienti informazioni a descrivere il contenuto, in modo da renderne più facile la ricerca o semplicemente l’interpretazione.
Assegnare nomi a oggetti e cose in generale è un’operazione naturale, quasi scontata per un essere umano, che da tempo immemore è abituato a “classificare” ed “etichettare” ciò con cui ha avuto a che fare. Da questo ha, poi, avuto origine il linguaggio, che gli ha consentito di fare un enorme passo in avanti rispetto al resto del regno animale.
Con un filesystem ciò non è soltanto “naturale”, ma diventa anche obbligatorio: un file deve necessariamente essere accompagnato da un nome, in modo da permettergli di poterlo collocare opportunamente nella struttura che utilizza per memorizzare sia i dati che gli altri metadati.
Arrivati a questo punto si chiude la copiosa parentesi e si pone il problema del case, quindi diventa lecito chiedersi: qual è la soluzione più “naturale”? Riflettiamo un momento su alcuni esempi che possono aiutare a comprendere meglio.
Ha senso nominare “a” e “A” due file nella stessa cartella? Se ho due foto del mio cane, le etichetterò forse con “Lassie” e “lassie”? Passando ad altro, due tabelle diverse di un database le potrò mai chiamare “Clienti” e “clienti”? E ancora, se faccio una ricerca su internet, ha senso ottenere risposte diverse se scrivo “microprocessore” e “Microprocessore“?
La domanda più importante, che è anche la chiave per capire tutto il discorso, e a cui bisogna rispondere in questi casi, è la seguente: quale (utile) informazione riesco a ricavare dalla sola differenza in termini di case?
E’ in questi termini che, a mio avviso, va inquadrato il problema della scelta del case in un filesystem.
Per me entità diverse comportano che la loro nomenclatura non possa differire soltanto per il case, perché tenderei a sovrapporle, ad assimilarle come eguali, e a renderle sostituibili. E’ nel mio naturale ordine di cose farlo.
Anzi, definire due oggetti diversi che differiscano per il solo case può facilmente portare a commettere errori: se sbaglio il case di una lettera vado a specificare una cosa diversa da ciò che volevo. Utilizzare il case sensitive offre poco valore aggiunto astrattamente, ma nessuno o addirittura negativo concretamente.
Ecco perché come essere umano trovo che la risposta che più rispecchia il mio modo di fare, la mia essenza, è: il filesystem dev’essere case insensitive.
Per lo meno questo il pensiero a cui sono arrivato dopo diversi anni di esperienza, che sarà sicuramente diverso da quello di tanti altri, ma che spero di avere sufficientemente e chiaramente illustrato affinché possa servire almeno da stimolo per una riflessione diversa sull’argomento.
