Thread: [Tuxcmd-dev-vfs] Koncepce VFS - cast 2.
Status: Beta
Brought to you by:
tbzatek
From: Tomas B. <sou...@bz...> - 2004-02-21 14:59:43
|
Konecne, po nekolika dnech spisovani: Tohle je jenom koncept, nacrt zhruba jak si predstavuju ze by to melo vypadat. Na jmena funkci se nedivejte, je to jenom tak splacane, parametry zhruba sedi, mozna by to u nekterych funkci chtelo vratit jeste nejaky ten VFSResult navic... Mozna je ta struktura mirne schizofrenni, kombinoval jsem zaklady VFS ze Seksi Commanderu a Tux Commanderu. Koukam ze jsem pri prochazeni struktury sveho VFS (teda aspon lokalni casti) dosel na dost smeti :) (proste se to za ten rok a pul vyvoje nahromadilo...) K datovym typum: ja vim ze vsichni asi budeme pouzivat Pascal, takze by to bylo bezpredmetne, ale urcite se casem najde nekdo (treba ja), kdo si napise plugin v Cecku nebo nejakem jinem kompatibilim jazyku. Takze doporucuju pouzivat tyto typy: PChar, LongBool (kvuli 32bit zarovnavani), Integer (=3Dint), Int64 (=3Dto jeste nevim, neco jako long uint?), klasicky Point= er. Vetsina funkci by taky mela byt oznacena jako cdecl; Toto je seznam funkci ktery by mel obsahovat kazdy VFS modul: Inicializacni funkce: type TVFSLogFunc =3D procedure(S: PChar); cdecl; =20 capVFS_nil=3D0; //nothing capVFS_List=3D1; capVFS_CopyOut=3D2; capVFS_CopyIn=3D4; capVFS_MkDir=3D8; capVFS_RmDir=3D16; capVFS_Multiple=3D32; //support multiple files capVFS_Delete=3D64; capVFS_Rename=3D128; capVFS_Execute=3D256; .... atd, proste maska operaci co plugin umi=20 procedure VFSInit(LogFunc: TVFSLogFunc); // provede vnitrni inicializaci a nastavi logovaci funkci procedure VFSDestroy; // pri zavirani uvolni sve alokovane prostredky function VFSCaps(const sExt:PChar):Integer; // vrati pro kazdou priponu masku co plugin umi - bude stacit 32 moznosti= ? snad ano... function VFSGetExts:PChar; // vrati seznam pripon, nejak oddeleny (asi strednik) procedure SetProtocolLogFunc(ProtoLogFunc: TVFSLogFunc); // tato druha logovaci funkce bude slouzit k vypisu hlasek vyplyvajici z = komunikace (FTP hlavne) - chci je mit oddelene od Debug logovaci funkce property BlockSize: guint32 read GetBlockSize write SetBlockSize; // Nastaveni velikosti bloku pri presunu dat Operace: //error codes (TVFSResult) cVFS_OK=3D0; cVFS_Failed=3D1; // taky No such file cVFS_Not_Supported=3D2; cVFS_Not_More_Files=3D3; cVFS_ReadErr=3D4; cVFS_UnknownUserPas=3D5; cVFS_PermissionDenied=3D6; function VFSOpen(const sName:PChar):TVFSResult; // otevre soubor (archiv) function VFSLogin(const user, pass:PChar):TVFSResult; // prihlasi se na FTP, SCP nebo SMB function VFSClose:TVFSResult; // zavre soubor; nebo taky logout function VFSMkDir(const sDirName:PChar):TVFSResult; // vytvori adresar. Co vic? function VFSRename(const sSrcName, sDstName:PChar):TVFSResult; // prejmenuje soubor/adresar function VFSRemove(const APath: PChar):TVFSResult; // smaze (=3Dprovede unlink) soubor/adresar (v Unixu je to jedno, v plugi= nu nutno testovat) function FileExists(const FileName: PChar; const Use_lstat: LongBool = =3D False): LongBool; // zjisti jestli soubor/adresar existuje. Use_lstat =3D jestli ma delat f= ollow symlinks function MakeSymLink(const NewFileName, PointTo: PChar):TVFSResult; // vytvori symlink. NewFileName =3D cesta + jmeno souboru noveho symlinku function Chmod(const FileName: PChar; const Mode: integer):TVFSResult= ; // proste Chmod. Mode je v klasickym unixovym formatu (libc), takze bity,= ne octal function Chown(const FileName: PChar; const UID, GID: integer):TVFSRe= sult; // to samy function ChangeTimes(APath: PChar; mtime, atime: Longint):TVFSResult; // zmeni casy u souboru (ctime se vetsinou nepouziva) function ChangeDir(const NewPath: PChar):TVFSResult; // pokusi se zmenit adresar a vrati hodnotu jestli ma na to pravo (treba = do /root to hodi hned chybu) property Path: PChar read GetPath write SetPath; // zjistovani aktualni nastavene cesty v pluginu function GetFileSystemSize(const APath: PChar): Int64; // vrati velikost FS - ta cesta je nepovinna, plati jenom pokud plugin ma= ve svem stromu vic namountovanych FS (typicky NFS) function GetFileSystemFree(const APath: PChar): Int64; // analogicky function GetFSID(const APath: PChar): Int64; // vrati nejake unikatni cislo FS, ktere identifikuje, ze soubor se nacha= zi na urcitem FS function GetFSLabel(const APath: PChar): PChar; // zase plati stejna poznamka jako u GetFileSystemSize function GetDirSize(APath: PChar): Int64; // projde rekurzivne cely strom od zadane cesty a vrati velikost celeho s= tromu procedure BreakGetDirSize; // zastavi vyse uvedene zjistovani velikosti Blokove operace: toto je obdoba klasickych unixovych funkci k pristupu k souboru - muze se pouzivat napr. i v prohlizeci (vymena misto mmap predpokladam nebude slozita - proste se bude cist soubor po blocich. function OpenFile(const APath: PChar; const Flags, Mode: integer; var= Error: integer): integer; // vrati filedescriptor function ReadFile(const FileDescriptor: integer; Buffer: Pointer; ABl= ockSize: integer; var Error: integer): integer; // Returns number of bytes read function WriteFile(const FileDescriptor: integer; Buffer: Pointer; By= tesCount: integer; var Error: integer): integer; // Returns number of bytes written function CloseFile(const FileDescriptor: integer): TVFSResult; function FileSeek(const FileDescriptor: integer; const AbsoluteOffset= : Int64; var Error: integer): Int64;=20 // vrati nastavenou pozici nebo -1 pri chybe function SendFile(const SrcFileDescriptor, DestFileDescriptor: intege= r; var AbsoluteOffset: integer; const BlockSize: integer; var Error: inte= ger): Int64;=20 // Returns number of bytes transferred - pouzivam k blokovemu presunu dat= (kopirovani), je to rychlejsi nez read a pak write; navic je to presun n= a urovni jadra, takze rychlejsi a mimo cache Vypis adresare a zjistovani informaci o souboru: TVFSItemType =3D (vRegular=3D0, vLink=3D1, vSymlink=3D2, vChardev=3D3, v= Blockdev=3D4, vDirectory=3D5, vFifo=3D6, vSock=3D7, vOther=3D8); PVFSItem =3D ^VFSItem; =20 TVFSItem =3D record FileName, LinkTo :PChar; iSize:Int64; iMode:Integer; iUID: Integer; iGID: Integer; ItemType:TVFSItemType; // time_t representing the time in seconds since 00:00:00 UTC, January = 1, 1970) } m_time: LongInt; a_time: LongInt; c_time: LongInt; // file date // DirRec.DateTime :=3D EncodeDate (1970, 1, 1) + (ExtractNumber (@Heade= r.MTime, 12) / 86400.0); = =20 end; function VFSListBegin(APath: PChar; var VFSItem:PVFSItem):TVFSResult; // pretoci pozici listingu na prvni soubor - rekne se tim ze se zacina vy= pis function VFSList(APath: PChar; var VFSItem:PVFSItem):TVFSResult; // vrati nejakou hodnotu az dojde na konec seznamu (to plati i pro VFSLis= tBegin pokud je adresar prazdny) function VFSFileInfo(AFileName: PChar; var VFSItem:PVFSItem):TVFSResu= lt; // vrati strukturu s informacema jenom o tom jednom souboru Co jeste neni doresene: (opravdu nevim co tim chtel basnik rici ;-D ) function VFSRun(const sName:String):TVFSResult; function VFSList(const sDir:String; iItemID:Integer; var VFSItem:TVFS= Item ):TVFSResult; function VFSRmDir(const sDirName:PChar):TVFSResult; function VFSCopyOut(const sSrcName, sDstName:String):TVFSResult; function VFSCopyIn(const sSrcName, sDstName:String):TVFSResult; noooo..... je toho dost a nebude to zase tak lehke implementovat jak se tak divam... -- Tom=E1=B9 B=BEatek |
From: Radek C. <rad...@ce...> - 2004-02-21 15:51:12
|
No jdes na to trochu zhurta. Jen nejdulezitejsi informace: 1) **** Kopirovani bude stylem a) rekni modulu ze chces soubor a kam ho chces (z kama apod) nebo b) chci prvnich 4kb ze souboru, pak dalsi atd. Podle mne se priklanis k za b). Proc? Podle mne je to zalezitosti modulu. Nehlede ze nektere soubory (virtualni) nemusi mit descriptory atd. Fakt si myslim za trochu abstrakce nezaskodi. Nac to tak pitvat? 2) **** vis proc jsem tam mel napr. zde: TVFSClose =function (g:TVFSGlobs):TVFSResult;cdecl; to g? aby to bylo thread safe. Hlavni program zaalokoval pocet byte, ktere si modul zazadal. Toto se nasledne predavalo funkcim. Tim padem bych mohl modul zavest vicekrat (treba pro vice vlaken) a nemusel se bat ze si navzajem prepisou data (jelikoz data se tim padem nadileji). Jelikoz modul (jako CODE) je v pameti zaveden jen jednou a sdili globalni promenne pro vsechny instance (s tim nic nenadelas) to je zalezitosti jadra. Teda az do dnesniho dne jsem si tim byl jist. Jiste mne presvedcis o opaku :). No a modul potrebuje mit nejake globalni data (teda mozna ne jak se divam ze predavas i descriptory, no ale sem tam se neco zhodi, treba pro list). function VFSListBegin(APath: PChar; var VFSItem:PVFSItem):TVFSResult; // pretoci pozici listingu na prvni soubor - rekne se tim ze se zacina vypis a jak si to zapamatuji ? Kdyz nemuzu mit globalni promenne? > function VFSRun(const sName:String):TVFSResult; no treba jsem mel pro nektere moduly i virtualni soubory (treba pro RPM, kde jich bylo nekolik a mezi nimi i spustitelny install a unistall:), no a ono se hodi vubec nekdy treba spustit neco z archivu (pokud to ma clovek asociovane)) > function VFSList(const sDir:String; iItemID:Integer; var VFSItem:TVFSItem ):TVFSResult; no to je kombinace tech tvych tri volani v jednom > function VFSRmDir(const sDirName:PChar):TVFSResult; k tomu se jeste vratim, ted musim jit rezat drevo. > function VFSCopyOut(const sSrcName, sDstName:String):TVFSResult; viz bod 1a > function VFSCopyIn(const sSrcName, sDstName:String):TVFSResult; viz bod 1b > > > > noooo..... je toho dost a nebude to zase tak lehke implementovat jak se > tak divam... no to teda asi ne :) VFS by melo byt o abstrakci. Jinak se z toho zeserem. Radek |
From: Tomas B. <sou...@bz...> - 2004-02-21 17:11:56
|
On Sat, 2004-02-21 at 16:49, Radek Cervinka wrote: > No jdes na to trochu zhurta. No vsak jo, jenom jsem to sepsal jake funkce potrebuju... > Jen nejdulezitejsi informace: > 1) > **** > Kopirovani bude stylem > a) rekni modulu ze chces soubor a kam ho chces (z kama apod) > nebo > b) chci prvnich 4kb ze souboru, pak dalsi atd. >=20 > Podle mne se priklanis k za b). Proc? Podle mne je to zalezitosti > modulu. Nehlede ze nektere soubory (virtualni) nemusi mit > descriptory atd. > Fakt si myslim za trochu abstrakce nezaskodi. Nac to tak pitvat? Hm... ja mam v programu v podstate obe dve koncepce, ale pro kopirovani pouzivam a). Proto ta implementace sendfile, coz je na lokalnim FS volani libc. Nechtel bych, aby se soubor zkopiroval cely na jedno volani funkce, mel by se taky nekde updatnou nejaky progress bar. Sendfile taky pracuje navic po blocich. Ty funkce co tam byly (read, write, seek, open, close) tam nejsou kvuli kopirovani, ale pro prime cteni dat (nepravidelne; random access). Napr. i pro interni prohlizec by se to dalo pouzit. Dalsi problem vidim v tom, pokud se bude kopirovat z jednoho pluginu do druhyho. V takovym pripade musi zdrojovy plugin dekodovat data, vratit ukazatel na pamet s urcitym blokem dat a pak cilovy plugin by mel ty data enkodovat a zapsat podle sveho. Jinak to asi nepude (doufam). >=20 > 2) > **** >=20 > vis proc jsem tam mel napr. zde: > TVFSClose =3Dfunction (g:TVFSGlobs):TVFSResult;cdecl; > to g? > aby to bylo thread safe. Hlavni program zaalokoval pocet > byte, ktere si modul zazadal. Toto se nasledne predavalo > funkcim. > Tim padem bych mohl modul zavest vicekrat (treba pro vice vlaken) > a nemusel se bat ze si navzajem prepisou data (jelikoz data se tim pade= m=20 > nadileji). > Jelikoz modul (jako CODE) je v pameti zaveden jen jednou > a sdili globalni promenne pro vsechny instance (s tim nic nenadelas) > to je zalezitosti jadra. Teda az do dnesniho dne jsem si tim byl jist. > Jiste mne presvedcis o opaku :). No vidis, s timhle jsem vubec nepocital... Ted uz mi je jasnejsi ta tvoje struktura. Tohle je samozrejme potreba. >=20 > No a modul potrebuje mit nejake globalni data (teda mozna ne > jak se divam ze predavas i descriptory, no ale > sem tam se neco zhodi, treba pro list). Descriptory nebo neco takoveho budou asi potreba, pokud si budes prohlizet treba dva soubory zaraz z jednoho archivu. > function VFSListBegin(APath: PChar; var VFSItem:PVFSItem):TVFSResult= ; > // pretoci pozici listingu na prvni soubor - rekne se tim ze se zacina = vypis >=20 > a jak si to zapamatuji ? Kdyz nemuzu mit globalni promenne? Nijak. Pomoci globalni promenne :) > > function VFSRun(const sName:String):TVFSResult; >=20 > no treba jsem mel pro nektere moduly i virtualni soubory > (treba pro RPM, kde jich bylo nekolik a mezi nimi i > spustitelny install a unistall:), > no a ono se hodi vubec nekdy treba spustit neco z archivu > (pokud to ma clovek asociovane)) Spoustet primo nejake aplikace bez predchoziho ulozeni na disk asi nejde (nebo mozna jo, ale nevim o tom), Total Commander to taky dela tak, ze si prvni rozbali ten soubor (prip. cely archiv) nekam do tmp a pak to pusti. Vpodstate staci operace kopirovani, spusteni si uz ohlida filemanager (aspon tak to mam teda namysleno), takze neni potreba zadne funkce VFSRun. > > function VFSList(const sDir:String; iItemID:Integer; var VFSItem:= TVFSItem ):TVFSResult; >=20 > no to je kombinace tech tvych tri volani v jednom OK a to iItemID je tam na co? > > function VFSRmDir(const sDirName:PChar):TVFSResult; > k tomu se jeste vratim, ted musim jit rezat drevo. Hodne stesti a bacha na ruky! ;D > > function VFSCopyOut(const sSrcName, sDstName:String):TVFSResult; > viz bod 1a > > function VFSCopyIn(const sSrcName, sDstName:String):TVFSResult; >=20 > viz bod 1b > >=20 > >=20 > >=20 > > noooo..... je toho dost a nebude to zase tak lehke implementovat jak = se=20 > > tak divam... > no to teda asi ne :) >=20 > VFS by melo byt o abstrakci. Jinak se z toho zeserem. Kvuli tomu je to potreba dukladne promyslet... > Radek >=20 ---- Tom=E1=B9 B=BEatek |
From: Radek C. <rad...@ce...> - 2004-02-21 20:07:49
|
>>/No jdes na to trochu zhurta./ >> > No vsak jo, jenom jsem to sepsal jake funkce potrebuju... OK >>/Jen nejdulezitejsi informace: >>1) >>**** >>Kopirovani bude stylem >>a) rekni modulu ze chces soubor a kam ho chces (z kama apod) >>nebo >>b) chci prvnich 4kb ze souboru, pak dalsi atd. >> >>Podle mne se priklanis k za b). Proc? Podle mne je to zalezitosti >>modulu. Nehlede ze nektere soubory (virtualni) nemusi mit >>descriptory atd. >>Fakt si myslim za trochu abstrakce nezaskodi. Nac to tak pitvat?/ >> > Hm... ja mam v programu v podstate obe dve koncepce, ale pro kopirovani > pouzivam a). Proto ta implementace sendfile, coz je na lokalnim FS > volani libc. Nechtel bych, aby se soubor zkopiroval cely na jedno volani > funkce, mel by se taky nekde updatnou nejaky progress bar. Sendfile taky > pracuje navic po blocich. To je lepsi resit callbackem, tj nejakou funkci typu TCallBack=Function ( iPos:Int64; iMax:Int64):Boolean; //cdecl; 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. function VFSCopyOut(pCallBackProgress:TCallback; const sSrcName, sDstName:String):TVFSResult; Navic tim ze je to fce muzu udelat to, ze nastavenim result na false muzu kopirovani abortnout :). tj. v moudulu begin while not oef(konec souboru) do begin kopiruj davku if not pCallbackProgress( iZkopirovano, iCelkem) then begin // sakra uzivatel to abortoval end; end; end; > Ty funkce co tam byly (read, write, seek, open, close) tam nejsou kvuli > kopirovani, ale pro prime cteni dat (nepravidelne; random access). Napr. > i pro interni prohlizec by se to dalo pouzit. Vis jak tezko se to bude implementovat? Predstav si, ze je to nejaky archiv, ktery ma nejaky tabulky (jako pro 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 vytvorit. Pak prijde pozadavek na byte 100-150, takze budu muset projit zase 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). > Dalsi problem vidim v tom, pokud se bude kopirovat z jednoho pluginu do > druhyho. V takovym pripade musi zdrojovy plugin dekodovat data, vratit > ukazatel na pamet s urcitym blokem dat a pak cilovy plugin by mel ty > data enkodovat a zapsat podle sveho. Jinak to asi nepude (doufam). no porozmyslej. ja bych to udelal pres nejaky temp (kdyz uz uzivatel chce takovou prasarnu) :) >>/> function VFSRun(const sName:String):TVFSResult; >> >>no treba jsem mel pro nektere moduly i virtualni soubory >>(treba pro RPM, kde jich bylo nekolik a mezi nimi i >>spustitelny install a unistall:), >>no a ono se hodi vubec nekdy treba spustit neco z archivu >>(pokud to ma clovek asociovane))/ >> > Spoustet primo nejake aplikace bez predchoziho ulozeni na disk asi nejde > (nebo mozna jo, ale nevim o tom), > Total Commander to taky dela tak, ze > si prvni rozbali ten soubor (prip. cely archiv) nekam do tmp a pak to > pusti. Vpodstate staci operace kopirovani, spusteni si uz ohlida > filemanager (aspon tak to mam teda namysleno), takze neni potreba zadne > funkce VFSRun. nepochopil, nepochopil :) Takze znovu. Nejlepe na RPM (coz jak jiste vis, jsou balicky pro redhat, MDK, Suse atd). Ekvivalentem je DEB pro Debian. (promin ze tak obsirne, vim ze to vis, ale presto). plugin pro rpm vylistuje obsah RPM a pridaval tam virtualne nekolik souboru - jeden obsahoval seznam souboru, dalsi info o baliku, dalsi a ted pozor pridal virtualni soubory (tedy neexistujici) install a unistall (a oznacil 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. Kdybys to vykopiroval tak ti houby pomuze, neb ten soubor je ciste virtualni a VFS ho virtualizuje. 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 podporovat (a pro to je tam to VFSCaps nebo jak se to jmenuje). >>/> function VFSList(const sDir:String; iItemID:Integer; var VFSItem:TVFSItem ):TVFSResult; >> >>no to je kombinace tech tvych tri volani v jednom/ >> > OK a to iItemID je tam na co? 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. tedy: VFSList vrati celej obsah archivu (A), nebo jen pro jeden level (B) (bez podaresaru). Ja jsem puvodne myslel tu variantu (B) a proto tam bylo to sDir. 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) Takze jsem pro 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. Jeste mne napadlo: Opet situace: uzivatel chce vykopirovat nekolik souboru z archivu. Stavajici navrh by postupne pro jednotlive soubory volal treba CopyOut nebo neco jineho, kazdopadne to znamena ze by se archiv prochazel vzdy znovu (coz jak jsem rekl u seqvencnich archivu je docela otrava). Lepsi by bylo nasypat pozadovane soubory a pak rict: ted je vykopiruj, vymaz, vkopiruj atd. To jen tak :). Radek |
From: Tomas B. <sou...@bz...> - 2004-02-21 22:38:21
|
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 |