Il 12 maggio 2013 12:01, Diego Barrera <diegonebarr...@yahoo.it> ha scritto: > Il 12/05/2013 11:03, Marco Beri ha scritto: > > 2013/5/12 Diego Barrera <diegonebarr...@yahoo.it> >> >> Se la struttura non e' molto grande, potresti gestirla facendo una >> copia di backup temporanea della struttura, se qualcosa va storto >> rimuovi la struttura corrotta e rinomini quella di backup. >> Ciao diego > > > Se potesse permetterselo (ma ha già detto che non può) la cosa giusta > sarebbe fare la copia su cui fare le modifiche e, solo come atto "atomico" > finale, fare una move sulla copia di backup. Qualunque cosa vada male, ha la > copia vera, attiva, senza problemi. Facendo come dici tu, se le cose vanno a > schifio tra la verifica della corruzione e la rinomina della copia di > backup, è fregato. > > Pensavo che fosse equivalente l'approccio > > > La parola chiave è "atomica". La rename dovrebbe essere una operazione > atomica a livello di file system e quindi va per forza usata quella se uno > vuole essere sicuro di fare un cambio solo finale che lo porta alla nuova > situazione. > > Certo, poi servirebbe anche che nessuno facesse modifiche alla struttura che > il programma ha copiato e su cui sta effettuando le modifiche. > > Per capire: i problemi di concorrenza e atomicita' delle operazioni sul > filesystem non sono intrinseci alla struttura da lui utilizzata? > > Altra riflessione: come approcciano i software di versioning al problema? >
vediamo se può essere d'aiuto la descrizione della procedura che utilizzavo nella versione in perl, praticamente ad ogni accesso in scrittura al file system, che fosse per creare una directory, o un file, e ad ogni accesso al sistema che implica l'utilizzo di device (quindi agganciare un'immagine ad un loop device, montare questo loop device in una directory temporanea) erano tutte registrate (atomicamente, prendendo in modo esclusivo l'accesso al file di rollback) in un file criptato (criptato, perché potendo essere eseguito tra due istanze diverse del programma, se qualcuno avesse messo semplicemente "/" come directory da cancellare, va da se che avrebbe distrutto l'intero sistema, visto che il programma gira con i permessi di root). nel momento in cui il programma avesse abortito per un qualsiasi motivo, se potevo catturare l'eccezione, eseguivo immediatamente il rollback, se non poteva essere eseguito subito, al successivo avvio del programma, la sola presenza del file di rollback ne provocava l'esecuzione e quindi il ristabilirsi della situazione precedente all'esecuzione andata a male. credo che alla fine mi ricostruirò una situazione del genere, esiste un qualche modo per intercettare automaticamente le varie funzioni che possano creare file/directory montaggio di immagini, assegnazione di loop device? potrei forse costruirmi una classe che vada ad aggiungere queste caratteristiche alla classica open in write/append mode? BYez -- Gollum1 Tesssssoro, dov'é il mio tessssoro... _______________________________________________ Python mailing list Python@lists.python.it http://lists.python.it/mailman/listinfo/python
