Re: [Tuxcmd-dev-vfs] Koncepce VFS - cast 2.

[Tomas B. <sou...@bz...>]

On Sat, 2004-02-21 at 21:06, Radek Cervinka wrote:

> To je lepsi resit callbackem, tj nejakou funkci typu
>=20
> TCallBack=3DFunction ( iPos:Int64; iMax:Int64):Boolean; //cdecl;
>=20
> no a tu funkce bude implementovana nekde v hlavnim programu,
> a kdyz ten modul uzna za vhodne ze by v ramci kodovani mohl
> oznamit nejakej progress tak ji jen zavola.
> Asi by se predavalo pri volani.
>=20
> function VFSCopyOut(pCallBackProgress:TCallback; const sSrcName,=20
> sDstName:String):TVFSResult;
>=20
> Navic tim ze je to fce muzu udelat to, ze nastavenim
> result na false muzu kopirovani abortnout :).
> tj. v moudulu
>=20
> begin
>    while not oef(konec souboru) do
>    begin
>      kopiruj davku
>      if not pCallbackProgress( iZkopirovano, iCelkem) then
>      begin
>        // sakra uzivatel to abortoval
>      end;
>    end;
>=20
>    end;



No... presne takhle to zatim mam udelane, ale chtel jsem se toho uz
konecne zbavit (na lokalu v tom neni rozdil). Jeste teda mam udelanej
druhej callback - errorovy (pokud nastane nejaka chyba pri kopirovani,
uzivatel muze kliknout na ignore a pokracovat v kopirovani - uzitecna
funkce pri kopirovani treba filmu z poskrabanych CD). V podstate je mne
to jedno, vyhoda pouziti callbacku by byla ta, ze plugin by si sam
urcoval velikost bloku po kterem zavola progress funkci...


> > Ty funkce co tam byly (read, write, seek, open, close) tam nejsou kvu=
li=20
> > kopirovani, ale pro prime cteni dat (nepravidelne; random access). Na=
pr.=20
> > i pro interni prohlizec by se to dalo pouzit.
>=20
> Vis jak tezko se to bude implementovat?
> Predstav si, ze je to nejaky archiv, ktery ma nejaky tabulky (jako pro=20
> kompresi), tj. pokud budu chtit dejme tomu  50 byte, tak budu muset mit
> ulozen slovnik z predchozich 49 byte (nebo je projit), nebo ho znova vy=
tvorit.
> Pak prijde pozadavek na byte 100-150, takze budu muset projit zase=20
> podelanych prvnich 99 byte. Vysledek > pomale, pomale, zabira to pamet,
> bude se to tezko psat (hlavne u sekvencnich archivu aka rar, kde pro
> x soubor musis projit x-1 predchozich).


No je mne to jasny ze to bude delat problemy. Jenze u nekterych pluginu
(typicky SMB) tato nevyhoda nebude, spousta pluginu bude umet nativne
seek (ted nemyslim ty archivacni), takze proc toho nevyuzit? Muzeme to
udelat tak, ze bud plugin primo vrati nejakej flag ze neumi primo seek a
filemanager pak bude vedet, ze musi soubor prvni rozbalit, nebo si to
bude sam obhospodarovat plugin (trochu silene).


> > Dalsi problem vidim v tom, pokud se bude kopirovat z jednoho pluginu =
do=20
> > druhyho. V takovym pripade musi zdrojovy plugin dekodovat data, vrati=
t=20
> > ukazatel na pamet s urcitym blokem dat a pak cilovy plugin by mel ty=20
> > data enkodovat a zapsat podle sveho. Jinak to asi nepude (doufam).
>=20
> no porozmyslej. ja bych to udelal pres nejaky temp (kdyz uz uzivatel ch=
ce=20
> takovou prasarnu) :)


Typicka situace: vykopirovani jednoho souboru z archivu na sitovy disk
(SMB). Vpodstate by se jednalo o sekvencni rozbaleni souboru, stejne
jako vykopirovani na lokalni disk...


> nepochopil, nepochopil :)
>=20
> Takze znovu. Nejlepe na RPM (coz jak jiste vis, jsou balicky pro redhat=
,=20
> MDK, Suse atd). Ekvivalentem je DEB pro Debian. (promin ze tak obsirne,=
 vim=20
> ze to vis, ale presto).
>=20
> plugin pro rpm vylistuje obsah RPM a pridaval tam virtualne nekolik sou=
boru
> - jeden obsahoval seznam souboru, dalsi info o baliku, dalsi a ted pozo=
r
> pridal virtualni soubory (tedy neexistujici) install a unistall (a ozna=
cil=20
> je jako spustitelne).
> Protoze je uzivatel liny a nechce se mu psat rpm -ibalik.rpm, tak
> po klepnuti na install se zavolalo VFSRun s parametrem install
> a plugin toto zjistit a provedl odpovidajici akci, tedy
> rpm -ibalik.rpm.
>=20
> Kdybys to vykopiroval tak ti houby pomuze, neb ten soubor je ciste=20
> virtualni a VFS ho virtualizuje.
>=20
>=20
> Da se to vyuzit jen v nekolika malo pripadech, ale ty jsou veskrze cool=
.
> Jsem vsemi 10 pro to aby to tam bylo. Vetsina modulu to nemusi podporov=
at
> (a pro to je tam to VFSCaps nebo jak se to jmenuje).


aha :) to jsem vazne nepochopil, protoze rpm uz delsi dobu nepouzivam,
nikdy jsem nedosel na to, ze je neco takoveho mozne... Strukturu rpm
samozrejme znam, ale nikdy jsem se nepidil po tom, co nektere soubory
znamenaji.=20
V takovem pripade by bylo dobre oznacit pri vypisu adresare (nebo pri
zadosti o info jednoho souboru), ze pri spusteni soubor nalezi k funkci
VFSRun a ne ze je to normalni spustitelny soubor.
BTW: tady asi budou problemy s rootem (predpokladam ze nikdo nebude
takovy silenec aby pustil nebezpecneho filemanagera pod rootem) - user
nebude mit pravo na instalaci baliku.


> > OK a to iItemID je tam na co?
>=20
> no to by mel byt ten index, tedy pro prvni zaznam je to 0, pro druhy je=
 to
> 1., to sDir melo puvodne myslenku, ale uz si ji nejsem tak jist.
>=20
> tedy:
> VFSList vrati celej obsah archivu (A), nebo jen pro jeden level (B) (be=
z=20
> podaresaru). Ja jsem puvodne myslel tu variantu (B) a proto tam bylo to=
 sDir.
>=20
> Obe maji sve pro a proti.
> varianta (B) je jednudussi pro hlavni program
> varianta (A) je jednodussi a ruchlejsi pro plugin.
> Problem u A je ze ho nemusi celej znat (napr. pro FTP)
>=20
> Takze jsem pro B.


Souhlas, jsem pro B. V nekterych pripadech by bylo mozna dobre, aby pri
otevreni archivu plugin prosel vsechno (varianta A) (nevim presne jak to
ma tar, ale asi to bude prave tento pripad) a vytvoril si nejaky interni
strom, ze ktereho se pak budou brat rychle casti pro VFSList typu B.


> > Kvuli tomu je to potreba dukladne promyslet...
> No ja kdyz jsem to navrhoval tak uz jsem par jinych
> programu vytvoril (a treba s tim tread safe to byla bolestna zkusenost)=
.
> Kdysi jsem o tom psal na root.cz celej clanek.


Na to se musim nekdy mrknout...


>=20
> Jeste mne napadlo:
>=20
> Opet situace: uzivatel chce vykopirovat nekolik souboru z archivu.
>=20
> Stavajici navrh by postupne pro jednotlive soubory volal treba CopyOut
> nebo neco jineho, kazdopadne to znamena ze by se archiv prochazel vzdy=20
> znovu (coz jak jsem rekl u seqvencnich archivu je docela otrava).
>=20
> Lepsi by bylo nasypat pozadovane soubory a pak rict: ted je vykopiruj,
> vymaz, vkopiruj atd.
>=20
> To jen tak :).
>=20
> Radek


Jo, to je dobrej napad... Zajimalo by me, jak tohle dela mc treba v
pripade taru - on ho ma rozbaleny (z gz/bz2) jako jeden soubor nekde v
tmp, ale stejne asi musi cely archiv projit pokud chce neco
vykopirovat...


----
Tom=E1=B9 B=BEatek