È arrivato il momento di fare un punto un po’ più ampio sulla 1.9.0. Negli ultimi aggiornamenti ho raccontato singoli pezzi: i progetti importati, i preset Unity, la navigazione, i primi esperimenti sulla compressione. Adesso quei pezzi vanno guardati insieme, perché l’obiettivo è una beta che contenga tutte le funzionalità previste per questa release e che abbia davvero senso mettere alla prova.
La beta non è ancora disponibile. Il lavoro è nel ramo di preparazione della 1.9.0, con la PR ancora in bozza. Questo è il diario pre-beta: cosa funziona già nel codice in sviluppo, quali problemi sono usciti dalle prove e quali passaggi restano da completare prima di distribuire i pacchetti.
Parto dalle cose che si vedono. Poi arriviamo a quelle che, in un programma di backup, spero non dobbiate mai notare nel momento sbagliato.
Un progetto non dovrebbe sparire perché è nato su un altro computer
Se importo una cronologia di backup da un’altra macchina, mi aspetto di ritrovare il progetto sotto Projects. Non di dover ricordare in quale angolo dell’app è finito.
La vista di sviluppo ora mantiene visibili anche i progetti registrati senza una cartella sorgente locale e li distingue con l’etichetta Imported. Provenienza e disponibilità della cartella sono due informazioni separate: collegare o ripristinare una cartella non cancella il fatto che quel progetto sia stato importato.
Quando la sorgente non è disponibile, le azioni che ne hanno bisogno restano disabilitate. La cronologia continua invece a essere consultabile per il recupero dei file. È una modifica piccola da descrivere, ma rende meno ambiguo usare gli stessi backup da computer diversi.
Schermata di sviluppo acquisita per il diario del 14 ottobre: rendering nativo della vera interfaccia con progetti sintetici e cartelle temporanee. La riprendo qui per il riepilogo pre-beta; non è una nuova acquisizione né una prova di recupero di un disco.
Prima di comprimere meglio, bisogna scegliere cosa salvare
Il controllo dei preset Unity è partito da una domanda molto pratica: come fa un progetto composto soprattutto da codice a produrre backup così grossi?
Non avevo ancora misurato il progetto segnalato sul server, quindi non sarebbe corretto attribuire tutti quei gigabyte a una singola causa. L’audit del codice ha però trovato problemi concreti: la risoluzione dei preset non era coerente in tutti i percorsi e le acquisizioni salvate del profiler Unity potevano finire nel backup dei sorgenti.
La risoluzione è stata resa coerente e il preset include ora le esclusioni per i file .pdata, insieme alle regole per cache e file generati. Le regole vanno comunque lette rispetto a ciò che si vuole conservare: un preset non può sapere da solo quali risultati di una build siano importanti per un progetto specifico.
Vista nativa già acquisita per il precedente diario, con dati dimostrativi. Mostra le regole corrette nell’editor esistente: non è una nuova interfaccia e non misura il progetto sul server.
Le esclusioni cambiano i file che entrano nel backup. La compressione cambia quanto spazio occupano quelli che abbiamo deciso di salvare. Separare le due cose evita di chiamare “compressione migliore” un archivio da cui abbiamo semplicemente tolto una cache.
Anche il pulsante Indietro deve ricordarsi dove eravamo
Un’altra parte del lavoro riguarda la navigazione tra le pagine: pulsanti Indietro e Avanti, scorciatoie Alt+Sinistra e Alt+Destra e ripresa dell’ultima pagina all’avvio.
La prova utile è stata lasciare History, aprire Settings e tornare indietro senza perdere filtri o lavoro non ancora salvato. Da lì è uscito anche un difetto: un aggiornamento della cronologia poteva ricostruire la selezione e far sparire bozze di etichette, note e tag. Le bozze vengono ora conservate per lo stesso progetto e snapshot durante la sessione.
La schermata in apertura mostra proprio quella cronologia di sviluppo. Il punto dimostrativo è Metadata only: descrive metadati presenti, non file già recuperabili. Mi interessa che l’app dica chiaramente la differenza, anche quando la risposta è meno rassicurante di un bel segno di spunta.
Il pezzo meno visibile: prima della prima scrittura
Il lavoro più recente è nel motore Linux per il recupero dei dischi. Qui non c’è ancora una nuova schermata da mostrare, ma c’è un confine importante da mettere a posto.
Controllare un’immagine una volta non basta se i byte che verranno scritti possono cambiare dopo quel controllo. Il percorso aggiornato fa ispezionare l’ingresso a un lettore separato prima di riservare spazio per la copia privata. Dopo la copia, il motore completa le scritture, chiude i propri accessi scrivibili e riapre gli stessi file in sola lettura. Il lettore controlla di nuovo quella copia: i risultati devono coincidere, compresa l’impronta SHA-256 dell’intero contenuto.
Il componente che prepara la scrittura verifica a sua volta i byte effettivamente aperti. Alla fine, una rilettura completa della destinazione deve corrispondere al contenuto verificato. Chi scrive può così confrontare byte e impronte senza interpretare nuovamente le strutture dell’immagine.
Se il lettore manca, fallisce o supera il tempo consentito, l’operazione viene rifiutata. Non c’è un percorso di ripiego che riporti quell’interpretazione nel componente principale.
Diagramma dell’implementazione in sviluppo. Non è una schermata dell’app né la prova che un sistema operativo sia stato recuperato e riavviato.
Il bug che era meglio trovare adesso
Una prova modifica intenzionalmente un file dopo la preparazione. Il risultato atteso è semplice: accorgersene prima di scrivere sulla destinazione.
Ha trovato un problema reale. Un buffer di lettura da 128 KiB poteva conservare vecchi dati anche dopo un cambio di posizione nel file. In un caso, il controllo iniziale ha quindi visto ancora quei dati e la scrittura è partita. La verifica finale ha rilevato la differenza e dichiarato il fallimento: il recupero non è stato segnalato come riuscito, ma il rifiuto arrivava troppo tardi.
Ho rimosso quel buffer dalle riaperture native in sola lettura. Le prove ripetute con metadati e contenuti modificati, su settori da 512 e 4096 byte, ora rifiutano l’operazione senza scritture sulla destinazione e ne chiudono l’accesso.
Il difetto è stato riprodotto nel percorso in sviluppo, usando dati sintetici e una VM usa e getta. Nessun disco personale è stato usato. Per una volta, vedere la barra di avanzamento ferma a zero era esattamente il risultato che cercavo.
Compressione e diagnostica: due lavori con confini diversi
Sul formato attuale sono già state fatte modifiche mirate alla politica ZIP. Su una prova locale con scene e prefab testuali generati, l’archivio è passato da 250.608 a 167.260 byte: circa un terzo in meno, pagando più tempo di compressione. È un risultato su quella prova, non una promessa su qualunque progetto Unity. Gli archivi esistenti non sono stati riscritti.
Il compressore personalizzato resta un esperimento separato. Il primo prototipo comprime meno di DEFLATE sui campioni misurati, quindi non avrebbe senso sostituire oggi un formato consolidato soltanto per averne uno nostro. La ricerca continua in secondo piano mentre finisco la 1.9.0.
Per rendere utile il periodo beta c’è anche il lavoro sulla diagnostica: errori, arresti e blocchi dell’interfaccia, non soltanto crash. La politica prevista per le build compilate esattamente come beta abilita l’invio tecnico strutturato per impostazione iniziale, rispettando un rifiuto già espresso e mantenendo i controlli per rivedere, disattivare e cancellare i report. Questa impostazione non passa alle build stabili.
I report hanno campi consentiti e limiti fissi: niente log grezzi, dump di memoria, contenuti dei progetti, percorsi, credenziali o identificatori persistenti di utente, dispositivo e sessione. Resta una funzione da qualificare nel pacchetto beta finale; non equivale a raccogliere tutto quello che l’app riesce a vedere.
Quindi, quanto manca?
L’ultimo controllo Release del 22 ottobre ha superato 2.061 test Core e 285 test Python, senza avvisi, errori o test saltati. Un’esecuzione dedicata in una VM Linux ha superato 36 casi sul lettore isolato e sulla preparazione privata dell’immagine. I controlli automatici riportati sulla PR e il quality gate Sonar sono passati sul commit verificato.
Sono risultati utili, ma quei 36 casi usano una destinazione in memoria e un journal di prova. Verificano confini e rifiuti; non dimostrano ancora il recupero di un filesystem o l’avvio di un sistema operativo. Un hash coincidente prova che coincidono i byte, non che il computer ripartirà.
Prima della beta restano l’autorizzazione del componente che può scrivere, la conferma esatta del disco da sovrascrivere, il supporto di recupero avviabile con la sua interfaccia e il ciclo completo di acquisizione, verifica, avvio e ripristino. Servono inoltre prove delle interruzioni, aggiornamenti da una versione installata, pacchetti firmati e le review richieste.
I quattro profili candidati sono GPT/UEFI con ext4 o NTFS, su settori da 512 o 4096 byte. Nessuno è ancora qualificato per il rilascio. Non c’è quindi una data della beta da annunciare in questo diario.
L’obiettivo è arrivare con tutte le funzionalità della 1.9.0, lasciando le altre tappe della famiglia 1.9 alle rispettive release. Preferisco usare il pre-beta per dire dove siamo davvero e raccogliere domande utili, invece di far sembrare concluso ciò che deve ancora passare una prova completa.
Se avete dovuto recuperare un disco, quale informazione vi è mancata di più prima di confermare la destinazione da sovrascrivere?
Codice, prove e limiti: PR #736 · Recovery test evidence · Compression measurements · Diagnostic policy