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
--
FreeBSD mailing list ([email protected])
http://www.freebsd.cz/listserv/listinfo/users-l
