Newsgroup: it.comp.java
Titolo: Aggiornamento file e integrità

Ciao,
supponiamo di avere un file composto da una sequenza di "record",
diciamo degli oggetti serializzati.
Se apro tale file con la DataOutputStream e mi metto a scrivere 
in coda al file e il salta la corrente, come mi ritrovo?
Questa domanda dipende prob.te dal filesystem sottostante, ma come
si fa a preservare quanto più possibile la "consistenza" del
file e controllare, casomai, l'integrità delle informazioni contenute?
-- 
Herbie

 file e controllare, casomai, l'integrità delle informazioni contenute?
Potresti, similmente al filesystem, usare anche te sul file un sistema 
di "journaling".
-- 
Giambo - Occhio al filtro antispam _e_ alla whitelist !

 di "journaling".
Uhm... suggerimento interessante, però il journalling è solo un modo per
_velocizzare_ il controllo dell'integrità, non mi pare aggiunga niente
alla verifica di integrità del filesystem. Vedi ext3 con ext2 (su cui
però devo indagare di più).
Il problema che mi pongo non è, in realtà, tanto controllare se ci sono
record danneggiati, ma se la scrittura su un file e un improvviso crash
possono spazzare via l'intero file. 
Quale metodo allora per aggiornare un file permettendo di ripristinare
l'ultima versione funzionante, ma senza avere due copie? (una originale e
una di lavoro, poi le scambio e cancello quella di lavoro, cioè la
vecchia).
Dovrei infatti fare aggiornamenti su un file molto grande e in tempi
rapidi.
-- 
Herbie

 alla verifica di integrità del filesystem. Vedi ext3 con ext2 (su cui
Ma come no. Il journaling è fatto a posta per migliorare la 
stabilità/integrità del fs per quanto ne so. Tant'è che se tiri via la 
spina da un linux ext2 a volte deve ricostruire mezzo mondo e magari non 
ci riesce neanche, con ext3 e gli altri fs journaled no.
Ma per il tuo caso non basta fare qualcosa tipo
- copiarsi il file vecchio
- accodare alla copia
- rinominare i due file?
Rimarrebbe scoperto solo il tempo in cui si rinomina, ma complicando un 
pò l'algoritmo si può certamente migliorare.
bye
DKano

 pò l'algoritmo si può certamente migliorare.
Da quel punto di vista basterebbe copiare il file originale in
uno ".old", modificare quello nuovo e alla fine cancellare quello .old. 
Se c'è un crash (e lo si sa perché c'è un .old in giro) si prende il 
.old e si considera come ultimo buono. Ma.. magari potessi!
-- 
Herbie

 rapidi.
E pensare di passare per un sistema transazionale, cioe' appoggiarsi su 
un piccolo db embedded (HSQLDB, Derby, H2) ?


 accennavo, devo lavorare con un file molto grosso e questo è
Ah, scusa non avevo letto. A questo punto in effetti qualche cosa di 
simil-journaling potrebbe esser utile. Però non so come si comporti il 
fs in caso di accodamento, cioé se esiste il rischio che ti 'sbielli' 
anche la parte esistente del file.
Come ti hanno suggerito, prova a valutare anche l'uso di un db embedded 
che ti garantisce la transazionalità
bye
DKano

 file e controllare, casomai, l'integrità delle informazioni contenute?
Nel frattempo ho trovato qualcosa che un po' mi conforta, pare che un
randomaccessfile aperto in rws dia la garanzia che quello che hai
scritto è stato effettivamente registrato su disco.
http://developers.sun.com/learning/javaoneonline/2005/coreplatform/TS-4141.pdf
(ma, in effetti, anche 
http://tinyurl.com/eulyu
 secondo costruttore - 
http://java.sun.com/j2se/1.4.2/docs/api/java/io/RandomAccessFile.html#RandomAccessFile(java.lang.String,%20java.lang.String)
L'unica cosa che non ho capito, è la differenza tra i modi rws e rwd,
nel senso che dicono che il secondo non scrive in modo sincrono i
meta-dati, tra cui immagino la dimensione del file. E allora, se prima
che quelli siano scritti c'è un crash, che succede? I dati sono a posto,
ma non è che il fs mi tronca il file e quindi li perdo??
-- 
Herbie