Versioning a "Recycle bin"

[Dan Lukes]

On 09/03/11 07:03, Jan Dušátko:
> Zakaznici si pomerne casto omylem mazou soubory

> nahradit /bin/rm nějakým skriptem

Tvuj prumerny zakaznik casto omylem smaze soubor a stane se mu to pri 
pouziti 'rm' na prikazove radce ?

To ja bych se obavam, ze pouziti binaru od 'rm' je jeden z tech mene 
pravdepodobnych zpusobu, jak ke smazani dojde.

To spis si budes muset "sednout" na syscall UNLINK a UNLINKAT - tim se o 
umyslu "smazat" dozvis jako prvni bez ohledu na to jaka primarni akce k 
nemu vedla.

> zajistujici presunuti do konkrétního adresare v ~/ dokud nedojde místo

Uvazil's, ze by ~ nemuselo treba taky byt na stejnem svazku jako mazany 
soubor ? Pak se budou data fyzicky kopirovat. Nejenze vznikne problem s 
tim, zda na to je misto, ale navic to u velkych souboru muze sakra 
dlouho trvat. O tom, ze zjistit domovsky adresar vlastnika souboru je 
dost netrivialni akce (a v nekterych okamzicich mozna dokonce nemozna) 
ani nemluvim. A dalsi komplikace nastane kvuli nutnosti odlisovat kdy 
mazes posledni link a kdy neposledni. A to uz vubec nemluvim o (mozne 
teoreticke) situaci, kdy aplikace vytvori soubor, otevre si na nej 
deskriptor, ten si necha a puvodni link/jmeno smaze - a teprve pak do 
souboru zapisuje. Ty udelas kopii v okamziku smazani jmena, v dobe, kdy 
tam jeste nebudou data.

Tim nerikam, ze to fakt nejde, ale asi o dva rady jednodussi by bylo, 
kdybysis pro takove soubory udelal adresar na kazdem svazku. Pak totiz 
stacilo operaci "unlink" zkonvertovat na operaci "rename". Zadne 
problemy s mistem, probehlo by to okamzite, u souboru by se zachoval 
nejen obsah, ale i rada dalsich informaci (extended atributy, datumy 
vytvoreni a modifikace a tak), bylo by jedno,z e je soubor otevreny a s 
jeho obsahem se jeste dodatecne manipuluje ...

No a to ma privadi k jede jedne moznosti, ne tak pekne - ale zase bys 
nepotreboval ten kernelovy modul a sedet na syscallech.

Az udelas tu strukturu na kazdem svazku do ktere budes ukladat ty 
odpadky tak k tomu taky napis normalniho user-space daemona, ktery bude 
opakovane pochazet disk (pripadne jen adresare, ktere si urcis) a 
zjistovat, kde jsou nejake nove soubory. Ke kazdemu z nich si 
preventivne poridi dalsi link do te tve odpadkove struktury. Takze pokud 
uzivatel soubor smaze, a to jakymkoliv zpusobem, jeho obsah nezmizi, 
protoze na nej bude existovat jeste jeden link. Ledaze by ho vytvoril a 
smazal prilis rychle (to je cena za tu jednodussi implementaci bez 
kerneloveho modulu)

V obou pripadech budes muset jeste udelat nejaky management toho 
odpadkoveho kose a taky udelat realne pouzitelny zpusob, jak se uzivatel 
ke svym "omylem smazanym" datum zase dostane.

> Resil jste někdo podobny problem? Podarilo se to?
 > A je to vůbec technicky mozne?

U systemu, od ktereho mas zdrojaky ? Tam je mozne skoro vsechno. Ovsem, 
jestli se ptas, zda to jde zaridit jednoduse - zmenou hodnoty v nejakem 
konfiguraku, nebo napatlanim nejakeho shelloveho scriptu, tak to ne.

  ------

Problem ma ovsem jeste jedno, trivialni, reseni. Rikal jsme ti to do 
telefonu. Rekni zakaznikum, ze naprava jejich chyb jsou placene 
vyceprace - obnoveni jednoho souboru stoji 500Kc. Ale jako vstricny krok 
jim ctyri soubory mesicne obnovis zdarma.

Slibuju, ze - i kdyz nevim, ktery fyzikalni zakon to zaridi - pocet 
"omylu" prudce poklesne. Prinejmensim tech, u kterych budou data 
shledana jako natolik dulezita, ze je nutne zadat tvuj cas a zaridit 
jejich obnovu.

Dan