Tutto nasce da una buona intenzione.
“Facciamo una struttura chiara, così tutti capiscono dove sono i file”.
Cartelle annidate, nomi lunghi, super descrittivi.
La struttura parla. Anzi, racconta tutta la storia del progetto.
Poi, un giorno, arriva la prima segnalazione.
Il file non si apre (ma esiste)
Su Windows, molti programmi (e non solo il sistema operativo) hanno limiti sulla lunghezza massima del percorso completo: cartelle + sottocartelle + nome file.
Quando questo limite viene superato:
- il file è visibile
- il file è copiabile
- ma non è apribile da alcune applicazioni
Non perché sia corrotto, ma perché il percorso è troppo lungo per essere gestito correttamente.
La “soluzione”?
Copiare il file sul desktop. Rinominare. Accorciare il percorso.
Funziona… ma è già un segnale che qualcosa non va.
Nei backup il problema esplode davvero
Nei sistemi di backup la situazione diventa più critica.
Molti software:
- riescono a salvare file con percorsi molto lunghi
- ma non riescono a cancellarli durante le fasi automatiche di retention e cleanup
Questo porta a effetti a catena:
- i file “non cancellabili” si accumulano
- lo spazio disponibile diminuisce drasticamente
- servono storage sempre più grandi, spesso inutilmente
- con costi crescenti per dischi, licenze e infrastruttura
E soprattutto: ciò che dovrebbe essere automatico diventa manutenzione manuale, interventi periodici, script, workaround, tempo perso dall’IT solo per “ripulire” ciò che il sistema non riesce più a gestire da solo.
Il paradosso
Più una struttura è “parlante”, più diventa fragile e costosa nel tempo.
La vera buona pratica
La chiarezza va progettata, non lasciata crescere all’infinito:
- limiti alla profondità delle cartelle
- nomi file chiari ma essenziali
- regole di naming pensate anche per sistemi operativi e backup
Perché una struttura efficace non deve solo essere leggibile dall’uomo, ma gestibile dalle macchine.
Vi è mai capitato di dover intervenire manualmente su un backup che “in teoria” avrebbe dovuto funzionare da solo?
