«Unexpected end of archive» — cosa significa e cosa si recupera comunque

L'errore esatto, e cosa ti sta dicendo

A seconda dello strumento che apre il file, la formulazione cambia ma il significato no. WinRAR mostra:

Unexpected end of archive, e spesso accanto ad esso The archive is either in unknown format or damaged.

7-Zip formula lo stesso guasto come Unexpected end of data o, quando il danno raggiunge l'inizio del file, Cannot open the file as archive. Su Linux o macOS, il comando unzip segnala unexpected end of file o il più preciso End-of-central-directory signature not found.

Tutte queste stringhe descrivono un'unica situazione: lo strumento è rimasto senza file prima di quanto il formato dicesse che dovrebbe. Uno ZIP o un RAR hanno una forma definita, con strutture precise che dovrebbero trovarsi in posti noti. Quando il file è più corto di quanto quella forma richieda, lo strumento raggiunge la fine in modo inaspettato e si ferma. È questo che significa «unexpected» qui. Non è un guasto casuale, e di solito non sono dati rimescolati. È un file a cui manca la parte finale.

Uno ZIP conserva il suo indice proprio alla fine

Per capire perché la mancanza della parte finale sia così dannosa, aiuta sapere com'è disposto uno ZIP. Un archivio sono due cose cucite insieme. Prima vengono le voci: ogni file che hai aggiunto, compresso e scritto uno dopo l'altro, ciascuno preceduto da una piccola intestazione locale che ne indica nome e dimensione. Seconda, dopo tutte le voci, viene la directory centrale: una tabella che elenca ogni file nell'archivio e l'esatto offset in byte in cui ciascuno inizia.

Uno ZIP memorizza prima i file e per ultima la directory che li elenca. Un download troncato perde la directory, non i file che la precedono.

La directory centrale è l'indice dell'archivio. Quando fai doppio clic su uno ZIP, lo strumento salta alla fine, legge quella directory e la usa per mostrarti l'elenco dei file. Mettere l'indice per ultimo è deliberato: permetteva al formato ZIP originale di aggiungere file a un archivio senza riscriverlo per intero. Il problema è che l'unica struttura di cui uno strumento ha bisogno per prima è l'unica struttura conservata per ultima, così qualsiasi danno che inizia alla fine del file cade in pieno sull'indice. È lo stesso schema che rende fragile un foglio di calcolo, perché un file .xlsx è in realtà uno ZIP con la propria directory alla fine.

Perché un download interrotto perde l'indice, non i file

Uno ZIP viene scritto e trasferito dall'inizio alla fine. Quando un download si blocca, una sincronizzazione cloud si arrende o si estrae una chiavetta USB a metà copia, il file che atterra sul tuo disco è ciò che è arrivato prima dell'interruzione: la parte iniziale è intatta e quella finale semplicemente non c'è. Poiché la directory vive alla fine, è la prima vittima di qualsiasi troncamento. Le voci vicine all'inizio, i file compressi veri e propri, sono lì intatte.

È tutta qui la ragione per cui l'errore è così recuperabile. Lo strumento non trova la directory, così si rifiuta di aprire l'archivio nel modo normale e segnala una fine inaspettata. Ma i file in sé non sono mai stati il problema. Una passata di riparazione ignora la directory mancante e percorre invece l'archivio dall'inizio, leggendo ogni intestazione locale, prendendo i dati compressi che la seguono e ricostruendo una directory nuova a partire da ciò che trova. L'archivio si riapre, elencando ogni voce sopravvissuta fisicamente.

Una verifica rapida distingue il troncamento da qualcosa di peggio: confronta la dimensione del file con l'originale, se la conosci. Un archivio di 240 MB arrivato come 180 MB è un troncamento da manuale, e i 60 MB mancanti non sono danneggiati, sono altrove. È anche per questo che riscaricare è la prima mossa. I byte mancanti esistono ancora alla sorgente, e una copia pulita batte qualsiasi recupero di una parziale. Se l'archivio veniva da un download web o da un allegato di posta, prova quella strada prima di riparare. La versione specifica di Windows di questa stessa storia, dove l'estrattore integrato di Esplora file è più severo degli strumenti qui sopra, è trattata in «La cartella compressa non è valida».

Estrazione parziale: tirare fuori ciò che è sopravvissuto

Quando non c'è una copia pulita disponibile, l'estrazione parziale è l'obiettivo realistico, e spesso è un risultato molto buono. Poiché ogni voce porta con sé la propria intestazione locale e il proprio blocco compresso, i file memorizzati prima del taglio sono indipendenti da quelli persi dopo di esso. Uno strumento di riparazione legge l'archivio in modo sequenziale e recupera ogni voce finché non raggiunge il punto in cui i dati sono stati troncati. Il risultato non è tutto o niente; è «sono tornati 42 file su 50», dove gli otto mancanti sono quelli che erano ancora in viaggio quando il trasferimento si è fermato.

C'è un caso limite che merita di essere nominato con onestà. Il file che si trova proprio in corrispondenza del taglio è spesso presente a metà: la sua intestazione e la prima parte dei suoi dati compressi sono arrivate, ma il resto no. Quel file può estrarsi come una versione troncata di sé stesso, o non decomprimersi affatto, a seconda del formato e di quanto avanti fosse caduto il taglio. Tutto ciò che lo precede si estrae in modo pulito. Quindi un'aspettativa ragionevole è: file completi fino al taglio, un file forse danneggiato al confine, e nulla oltre. L'opzione «mantieni i file danneggiati» di WinRAR e le impostazioni equivalenti di altri strumenti esistono proprio per scrivere quel file di confine per quel che vale.

Quando davvero non c'è nulla da fare

La riparazione strutturale ricostruisce l'indice attorno ai dati sopravvissuti. Non può fabbricare dati che non ci sono, e alcune situazioni esulano da ciò che qualsiasi strumento può fare. Essere diretti su di esse ti fa risparmiare tempo:

• Il danno è a metà del flusso, non alla fine. DEFLATE, la compressione che usa lo ZIP, non ha ridondanza: è un flusso continuo in cui ogni parte dipende da ciò che è venuto prima. Se ci sono byte corrotti o mancanti dentro il blocco compresso di un file, invece di un taglio pulito alla fine, la decompressione perde la sincronia in corrispondenza del danno e tutto ciò che segue quel punto del file è irrecuperabile. Potresti comunque ottenere l'inizio di quel file, ma non il file intero.
• L'archivio è cifrato. Un archivio protetto da password o cifrato con AES può essere riparato strutturalmente, con la sua directory ricostruita e le sue voci di nuovo elencate, ma i dati compressi restano cifrati. Senza la password, le voci recuperate non possono essere decifrate in file utilizzabili. La riparazione sistema il contenitore; non rompe la cifratura, e nessuno strumento legittimo afferma il contrario.
• Manca una parte necessaria di un set multivolume. Un archivio diviso (.z01, .z02, o .part1.rar e simili) memorizza un unico flusso continuo ripartito su più file. Se una parte intermedia non è mai arrivata, il flusso ha un vero e proprio buco, e i volumi successivi al buco non possono essere uniti a quelli precedenti.
• Il file è quasi vuoto. Un archivio tornato come pochi kilobyte di un originale di diversi megabyte, o che si legge come quasi tutti zeri, non contiene voci reali da recuperare. Quello è un problema di download o di recupero, non di riparazione.

Al di fuori di questi casi, un archivio troncato è uno dei problemi di corruzione più benevoli da affrontare, perché la disposizione stessa del formato rende i file sopravvissuti raggiungibili uno alla volta.