Il 19/11/2014 13:53, Felipe ha scritto:
L'ho chiamato file binario perchè tutti lo chiamano così: in realtà credo che si tratti di un file indexed o comunque ad accesso random, che è costituzionalmente più debole di un file di testo tout court perchè la sua integrità dipende anche, credo, da una catena di puntatori.In data mercoledì 19 novembre 2014 13:03:11, Gian Uberto Lauri ha scritto:Se capita con un file binario, nel miglore dei casi il programma termina spontaneamente rivelando l'errore, in altri casi può morire generando un core. In casi particolarmente sfigati - probabilità praticamente nulla ma non con probabilità 0 - potresti persino autogenerarti un buffer overflow :).Aspetta, la mia domanda era specificamente riferita alla robustezza, in caso di deterioramento, del formato binario rispetto al testo, non sulla possibile difficoltà di accesso al file in se. Che le applicazione preposte all'accesso di un file binario corrotto possano dare problemi è un altro film. Io penso comunque che i programmi usati per leggere questi file non si lascino incastrare da un file corrotto, almeno utmpdump se ne frega se pasticci su wtmp, ti mostra eventualmente parti di log danneggiate, come è giusto che sia. Ciao -- felipe
Che poi si riesca a ricostruirlo anche se è corrotto, questo è un altro discorso (e un'altra perdita di tempo): e comunque le parti danneggiate restano illeggibili.
Con il log in formato testuale è molto più difficile che ciò avvenga, semplicemente perchè il log si limita ad accodare in fondo al file le nuove richieste; in un file con accesso random indexed le scritture possono avvenire in ogni parte del file, ci sono dei puntatori ecc...
utmtump è un dump: se hai un file danneggiato che contiene valori binari che devono essere interpretati in base a una specifica normativa e non conosci esattamente la struttura del file credo che difficilmente riesci a cavarci qualcosa di utile in tempi ragionevoli.
Luciano