tuxcmd-dev-vfs Mailing List for Tux Commander
Status: Beta
Brought to you by:
tbzatek
Menu
▾
▴
tuxcmd-dev-vfs — VFS development for various filemanagers
You can subscribe to this list here.
| 2004 |
Jan
|
Feb
(11) |
Mar
(3) |
Apr
(1) |
May
(1) |
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|---|
|
From: <ben...@id...> - 2004-05-25 09:48:40
|
Dear Open Source developer I am doing a research project on "Fun and Software Development" in which I kindly invite you to participate. You will find the online survey under http://fasd.ethz.ch/qsf/. The questionnaire consists of 53 questions and you will need about 15 minutes to complete it. With the FASD project (Fun and Software Development) we want to define the motivational significance of fun when software developers decide to engage in Open Source projects. What is special about our research project is that a similar survey is planned with software developers in commercial firms. This procedure allows the immediate comparison between the involved individuals and the conditions of production of these two development models. Thus we hope to obtain substantial new insights to the phenomenon of Open Source Development. With many thanks for your participation, Benno Luthiger PS: The results of the survey will be published under http://www.isu.unizh.ch/fuehrung/blprojects/FASD/. We have set up the mailing list fa...@we... for this study. Please see http://fasd.ethz.ch/qsf/mailinglist_en.html for registration to this mailing list. _______________________________________________________________________ Benno Luthiger Swiss Federal Institute of Technology Zurich 8092 Zurich Mail: benno.luthiger(at)id.ethz.ch _______________________________________________________________________ |
|
From: Tomas B. <sou...@bz...> - 2004-04-16 19:49:25
|
No, tak jsem neco spatlal a uz to castecne i pouzivam (zatim jenom experimenty). Sloucil jsem to do jednoho souboru, typy i deklarace funkci. Mam to funkcni i v Cecku, ale to zatim posilat nebudu, pockam az se ustali API tohohle. Par pripomniek: - VFSInit volam pred kazdym otevrenim VFS, tzn. prvni VFSInit, pak VFSOpen a pak prip. VFSLogin. Pri druhem soucasnem pouziti tehoz modulu se zase zavola VFSInit atd... - VFSInit inicializuje TVFSGlobs, ktere ale uz musi byt alokovane predem - to, ze plugin nejakou funkci nepodporuje, by se melo zjistovat, jestli je v library exportovany symbol, prip. vracet jako VFSResult hodnotu NotImplemented (nebo co to tam je) - porad nevim, jak vyresime to kopirovani. Dal jsem tam zatim ty dve procedury CopyIn a CopyOut, protoze to bude asi nejcastejsi pouziti, ale co delat pri presunu dat mezi dvema pluginama? Pres temporary file bych to vazne nechtel delat. Tady uz by se asi musely pouzit ty dalsi funkce read/write/seek a delat to rucne pres pametove bloky dat Jinak tomu vesmes uz nic nechybi... - pridal jsem si par informacnich funkci, aby uzivatel vedel, s cim ma tu cest ;-) Zatim pracuju na gnome-vfs modulu, ktery vypada velice slibne, akorat mne ted ceka vyresit autentizaci, takze mozna jeste budou v nasem VFS API nejake zmeny (ale nebudou radikalni, je to jenom autentizace) ---- Tomáš Bžatek |
|
From: Tomas B. <sou...@bz...> - 2004-03-16 19:37:09
|
On Tue, 2004-03-16 at 09:10, Radek Cervinka wrote: > mi se to libi az na : >=20 > > capVFS_Multiple=3D32; //support multiple files > co to je? > jak plugin oznaci ze neumi pohybovani ve streamu? to ja nevim co to je, tos tam mel ty ;) Ty capabilities by to jeste chtelo predelat, podle toho, jake funkce budeme mit v API (asi to udelame az nakonec). Jedno cislo z toho by taky melo oznacovat, jestli umi cist primo ze streamu... > Vsude chybi volaci konvence cdecl; jo :) ale to az nakonec > a jeste aby vsechny funkce zacinaly VFS > takze=20 >=20 > > function FileExists(g:TVFSGlobs; const FileName: PChar; const Use= _lstat: LongBool =3D False): LongBool;> function VFSFileExists(g:TVFS= Globs; const FileName: PChar; const Use_lstat: LongBool =3D False): LongB= ool; souhlas > > function ChangeTimes(g:TVFSGlobs; APath: PChar; mtime, atime: Lon= gint):TVFSResult; >=20 > > // zmeni casy u souboru (ctime se vetsinou nepouziva) > ale neznamena ze tam v rozhrani nebude no pri listovani ctime samozrejme je, nevim jestli to ma nejaky vyznam (asi jo, pro komplexnost bysme to tam asi meli dat). takze: function VFSChangeTimes(g:TVFSGlobs; APath: PChar; mtime, atime, ctime: L= ongint):TVFSResult; > > function GetFSID(g:TVFSGlobs; const APath: PChar): Int64; > > // vrati nejake unikatni cislo FS, ktere identifikuje, ze soubor se n= achazi na urcitem FS > no nevim hmmm tohle ma vyznam spis na lokalu ve strome /, mozna by to melo jeste smysl na SMB (ale tim si opravdu nejsem jist). Je mozno vyhodit pokud se nenalezne zadny plugin ktereho by se to tykalo ;-) Pouzivam to k identifikaci stejneho FS pri presouvani souboru (mezi ruznyma FS se musi prvni zkopirovat a smazat). > > function GetFSLabel(g:TVFSGlobs; const APath: PChar): PChar; > > // zase plati stejna poznamka jako u GetFileSystemSize > taky nevim Toto je asi stejny pripad jako predesla funkce - patrne to nebude zadny plugin pouzivat (maximalne zase SMB pri konexi na windows disk). > to by se delalo asi pres blokove operace nebo pres mmap (coz by bylo le= psi). > Jeden plugin by to namapoval do pameti a druhemu by se predal pointer n= a pamet a delka no... nejdriv asi budu muset detailne pochopit jak vubec mmap pracuje. Pouziti mmap z libc je mne jasne ale vazne nevim jak by se to uzivatelsky implementovalo. Predpokladam ze tam bude nejaky callback ze zdrojoveho pluginu pokud nejaky proces (cilovy plugin) bude chctit cist nejaky blok z pameti - tak callback funkce se pak postara o dekompresi dat (aspon tak to chapu). > =20 > > // DirRec.DateTime :=3D EncodeDate (1970, 1, 1) + (ExtractNumber (@H= eader.MTime, 12) / 86400.0); > jo to ExtractNumber je tam navic (to byla takova suport rutina): > EncodeDate (1970, 1, 1) + MTime / 86400.0); hmmm ja stejne pracuju s unixovym formatem (i interne v aplikaci)... To to budem muset v kazdem pluginu normalizovat... > > function VFSList(g:TVFSGlobs; const sDir:String; iItemID:Integer;= var VFSItem:TVFSItem):TVFSResult; > > // vylistuje seznam souboru v urcite ceste > ja si tady tim nejsem moc jist (a to jsem to vymyslel) > Lepsi byl asi sekvencni pristup jako FindFirst, FindNext, FindClose no... v nekterych pripadech to pocitadlo stejne bude muset byt interne v pluginu, v nektrerych je zase lepsi kdyz se to bude sypat postupne (FTP). Udelal bych nejakou funkci, ktera by vracela pointer na polozky nebo nil pokud bude konec seznamu. Pouziti funkci Findxxxx by celkem vyhovovalo. >=20 > > function VFSFileInfo(g:TVFSGlobs; AFileName: PChar; var VFSItem:P= VFSItem):TVFSResult; > > // vrati strukturu s informacema jenom o tom jednom souboru > to bych sem nedaval zbytecne to bude kompikovat plugin bude, ale je to docela nutne potrebuju k chodu programu. Pouzivam to hlavne ke zjisteni okamziteho stavu souboru - pokud potrebuju pracovat jen s jednim - jinak by se musel vylistovat znovu cely adresar a bylo by to neefektivni. Stejne ale bude potreba v nekterych pripadech projit=20 Je mi jasne ze nektere moje navrhy funkci docela zesloziti implementaci pluginu, ale na druhou stranu zrychli a zefektivni vyslednou aplikaci - navic proc to neimplementovat kdyz to nektere pluginy budou umet bez potizi (tyka se to i nekterych druhu archivu).=20 ---- Tom=E1=B9 B=BEatek |
|
From: Radek C. <rad...@ce...> - 2004-03-16 08:10:37
|
mi se to libi az na : > capVFS_Multiple=32; //support multiple files co to je? jak plugin oznaci ze neumi pohybovani ve streamu? Vsude chybi volaci konvence cdecl; a jeste aby vsechny funkce zacinaly VFS takze > function FileExists(g:TVFSGlobs; const FileName: PChar; const Use_lstat: LongBool = False): LongBool;> function VFSFileExists(g:TVFSGlobs; const FileName: PChar; const Use_lstat: LongBool = False): LongBool; > function ChangeTimes(g:TVFSGlobs; APath: PChar; mtime, atime: Longint):TVFSResult; > // zmeni casy u souboru (ctime se vetsinou nepouziva) ale neznamena ze tam v rozhrani nebude > function GetFSID(g:TVFSGlobs; const APath: PChar): Int64; > // vrati nejake unikatni cislo FS, ktere identifikuje, ze soubor se nachazi na urcitem FS no nevim > function GetFSLabel(g:TVFSGlobs; const APath: PChar): PChar; > // zase plati stejna poznamka jako u GetFileSystemSize taky nevim > function VFSRun(g:TVFSGlobs; const sName:String):TVFSResult; > // nainstaluje(prip. provede jinou akci) balicek rpm ci deb dekuji > > Blokove operace: > > > > !!! Sporne funkce - kopirovani: > TCallBackFunc = Function (iPos:Int64; iMax:Int64):Boolean; > > function VFSCopyOut(g:TVFSGlobs; const sSrcName, sDstName:String; pCallBackProgress: TCallBackFunc):TVFSResult; > function VFSCopyIn(g:TVFSGlobs; const sSrcName, sDstName:String; pCallBackProgress: TCallBackFunc):TVFSResult; > // Kopirovani souboru - zevnitr ven a zvenku dovnitr > // - tady jsme ale porad nedoresili co delat v pripade kopirovani mezi dvema VFS (z archivu na SMB disk, ze SMB na FTP...) - aby se nepouzival zadny temp soubor to by se delalo asi pres blokove operace nebo pres mmap (coz by bylo lepsi). Jeden plugin by to namapoval do pameti a druhemu by se predal pointer na pamet a delka > ale tohle bych precejenom implementoval: > (ikdyz zpocatku to nebude nutne, rad bych to ale chtel mit v programu > kvuli random pristupu k obsahu souboru treba na SMB disku (prohlizec) - > je jasne ze v nekterych pluginech to nepujde implementovat - v takovem > pripade bych to vracel ve funkci VFSCaps) popremislej o tom mmap > > function OpenFile(g:TVFSGlobs; const APath: PChar; const Flags, Mode: integer; var Error: integer): integer; > // vrati filedescriptor > function ReadFile(g:TVFSGlobs; const FileDescriptor: integer; Buffer: Pointer; ABlockSize: integer; var Error: integer): integer; > // Returns number of bytes read > function WriteFile(g:TVFSGlobs; const FileDescriptor: integer; Buffer: Pointer; BytesCount: integer; var Error: integer): integer; > // Returns number of bytes written > function CloseFile(g:TVFSGlobs; const FileDescriptor: integer): TVFSResult; > function FileSeek(g:TVFSGlobs; const FileDescriptor: integer; const AbsoluteOffset: Int64; var Error: integer): Int64; > // vrati nastavenou pozici nebo -1 pri chybe > // DirRec.DateTime := EncodeDate (1970, 1, 1) + (ExtractNumber (@Header.MTime, 12) / 86400.0); jo to ExtractNumber je tam navic (to byla takova suport rutina): EncodeDate (1970, 1, 1) + MTime / 86400.0); > end; > > function VFSList(g:TVFSGlobs; const sDir:String; iItemID:Integer; var VFSItem:TVFSItem):TVFSResult; > // vylistuje seznam souboru v urcite ceste ja si tady tim nejsem moc jist (a to jsem to vymyslel) Lepsi byl asi sekvencni pristup jako FindFirst, FindNext, FindClose > function VFSFileInfo(g:TVFSGlobs; AFileName: PChar; var VFSItem:PVFSItem):TVFSResult; > // vrati strukturu s informacema jenom o tom jednom souboru to bych sem nedaval zbytecne to bude kompikovat plugin Radek Cervinka |
|
From: Tomas B. <sou...@bz...> - 2004-03-15 21:20:39
|
Tak je tu druhe kolo s opravenyma specifikacema VFS. Predem se omlouvam
za dlouhe prodlevy mezi odpovedmi, jsem v pracovnim procesu a tudiz
nemam momentalne na nic cas :-(
Pridal jsem do kazde funkce parametr typu TVFSGlobs, ktery stejne
zustane skryty pro program, pokud si to clovek predela do objektu (treba
tak jak je to v uVFSmodule.pas).
Meli bychom bysme se domluvit hlavne na funkcich pro blokove operace s
daty, vsechen ostatni balast neni zas tak moc dulezity.
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(g:TVFSGlobs; LogFunc: TVFSLogFunc; Var iMemoryNeed:=
Integer);
// provede vnitrni inicializaci a nastavi logovaci funkci
procedure VFSDestroy(g:TVFSGlobs);
// pri zavirani uvolni sve alokovane prostredky
function VFSCaps(g:TVFSGlobs; const sExt:PChar):Integer;
// vrati pro kazdou priponu masku co plugin umi - bude stacit 32 moznosti=
? snad ano...
function VFSGetExts(g:TVFSGlobs):PChar;
// vrati seznam pripon, nejak oddeleny (asi strednik)
procedure SetProtocolLogFunc(g:TVFSGlobs; 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(g:TVFSGlobs): guint32 read GetBlockSize write SetB=
lockSize;
// Nastaveni velikosti bloku pri presunu dat - v nekterych pluginech nebu=
de pouzito (dynamicka velikost bloku)
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(g:TVFSGlobs; const sName:PChar):TVFSResult;
// otevre soubor (archiv)
function VFSLogin(g:TVFSGlobs; const user, pass:PChar):TVFSResult;
// prihlasi se na FTP, SCP nebo SMB
function VFSClose(g:TVFSGlobs):TVFSResult;
// zavre soubor; nebo taky logout
function VFSMkDir(g:TVFSGlobs; const sDirName:PChar):TVFSResult;
// vytvori adresar. Co vic?
function VFSRename(g:TVFSGlobs; const sSrcName, sDstName:PChar):TVFSR=
esult;
// prejmenuje soubor/adresar
function VFSRemove(g:TVFSGlobs; const APath: PChar):TVFSResult;
// smaze (=3Dprovede unlink) soubor/adresar (v Unixu je to jedno, v plugi=
nu nutno testovat)
function FileExists(g:TVFSGlobs; const FileName: PChar; const Use_lst=
at: LongBool =3D False): LongBool;
// zjisti jestli soubor/adresar existuje. Use_lstat =3D jestli ma delat f=
ollow symlinks
function MakeSymLink(g:TVFSGlobs; const NewFileName, PointTo: PChar):=
TVFSResult;
// vytvori symlink. NewFileName =3D cesta + jmeno souboru noveho symlinku
function Chmod(g:TVFSGlobs; const FileName: PChar; const Mode: intege=
r):TVFSResult;
// proste Chmod. Mode je v klasickym unixovym formatu (libc), takze bity,=
ne octal
function Chown(g:TVFSGlobs; const FileName: PChar; const UID, GID: in=
teger):TVFSResult;
// to samy
function ChangeTimes(g:TVFSGlobs; APath: PChar; mtime, atime: Longint=
):TVFSResult;
// zmeni casy u souboru (ctime se vetsinou nepouziva)
function ChangeDir(g:TVFSGlobs; const NewPath: PChar):TVFSResult;
// pokusi se zmenit adresar a vrati hodnotu jestli ma na to pravo (treba =
do /root to hodi hned chybu)
function GetPath(g:TVFSGlobs): PChar;
// zjistovani aktualni nastavene cesty v pluginu
function GetFileSystemSize(g:TVFSGlobs; 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(g:TVFSGlobs; const APath: PChar): Int64;
// analogicky
function GetFSID(g:TVFSGlobs; const APath: PChar): Int64;
// vrati nejake unikatni cislo FS, ktere identifikuje, ze soubor se nacha=
zi na urcitem FS
function GetFSLabel(g:TVFSGlobs; const APath: PChar): PChar;
// zase plati stejna poznamka jako u GetFileSystemSize
function GetDirSize(g:TVFSGlobs; APath: PChar): Int64;
// projde rekurzivne cely strom od zadane cesty a vrati velikost celeho s=
tromu
procedure BreakGetDirSize(g:TVFSGlobs);
// zastavi vyse uvedene zjistovani velikosti
function VFSRun(g:TVFSGlobs; const sName:String):TVFSResult;
// nainstaluje(prip. provede jinou akci) balicek rpm ci deb
Blokove operace:
!!! Sporne funkce - kopirovani:
TCallBackFunc =3D Function (iPos:Int64; iMax:Int64):Boolean;
function VFSCopyOut(g:TVFSGlobs; const sSrcName, sDstName:String; pCa=
llBackProgress: TCallBackFunc):TVFSResult;
function VFSCopyIn(g:TVFSGlobs; const sSrcName, sDstName:String; pCal=
lBackProgress: TCallBackFunc):TVFSResult;
// Kopirovani souboru - zevnitr ven a zvenku dovnitr
// - tady jsme ale porad nedoresili co delat v pripade kopirovani mezi d=
vema VFS (z archivu na SMB disk, ze SMB na FTP...) - aby se nepouzival za=
dny temp soubor
ale tohle bych precejenom implementoval:
(ikdyz zpocatku to nebude nutne, rad bych to ale chtel mit v programu
kvuli random pristupu k obsahu souboru treba na SMB disku (prohlizec) -
je jasne ze v nekterych pluginech to nepujde implementovat - v takovem
pripade bych to vracel ve funkci VFSCaps)
function OpenFile(g:TVFSGlobs; const APath: PChar; const Flags, Mode:=
integer; var Error: integer): integer;
// vrati filedescriptor
function ReadFile(g:TVFSGlobs; const FileDescriptor: integer; Buffer:=
Pointer; ABlockSize: integer; var Error: integer): integer;
// Returns number of bytes read
function WriteFile(g:TVFSGlobs; const FileDescriptor: integer; Buffer=
: Pointer; BytesCount: integer; var Error: integer): integer;
// Returns number of bytes written
function CloseFile(g:TVFSGlobs; const FileDescriptor: integer): TVFSR=
esult;
function FileSeek(g:TVFSGlobs; const FileDescriptor: integer; const A=
bsoluteOffset: Int64; var Error: integer): Int64;=20
// vrati nastavenou pozici nebo -1 pri chybe
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);
end;
function VFSList(g:TVFSGlobs; const sDir:String; iItemID:Integer; var=
VFSItem:TVFSItem):TVFSResult;
// vylistuje seznam souboru v urcite ceste
function VFSFileInfo(g:TVFSGlobs; AFileName: PChar; var VFSItem:PVFSI=
tem):TVFSResult;
// vrati strukturu s informacema jenom o tom jednom souboru
----
Tom=E1=B9 B=BEatek
|
|
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 |
|
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 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 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 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: Tomas B. <sou...@bz...> - 2004-02-17 13:32:52
|
On Tue, 2004-02-17 at 08:53, Ji=F8=ED Blahovsk=FD wrote: > Omouvam se za zpozdeni, nebot jsem byl tri dny v praci :-( OK, kazdy dela neco, ma ruzne cas; me ted treba vyhodili ze skoly... > > Takze: kazdy VFS modul by mel byt jako samostatny plugin (klasicka=20 > > .so), napsany s presne definovanym API. Pluginy by se mely natahovat=20 > > pri startu programu, kazdy plugin by mel obsahovat funkce, ktere=20 > > nejakym zpusobem vrati moznosti pluginu >=20 > Nejlepe asi pres writeln() ? Trochu se vytratil smysl, ale jestli to je k tomu logovani, tak by bylo asi nejlepsi pres nejakou funkci ktera se preda pluginu jako parametr pri inicializaci - jak uz tady bylo receno. Kazdy si pak tu logovaci funkci implementuje sam, treba ten writeln; > To by bylo moudre, nicmene v tomto jsem jeste dost veci > neprekousl. Nepodarilo se mi rozchodit ani mount() pres libc. Budto > to nefunguje nebo jsem to nepochopil, tak jsem zvolil cestu > nejmensiho odporu pres externi prikaz(docasne). K tomu mountovani: man 2 mount: "Only the super-user may mount and unmount filesystems." Ja uz jsem svuj mounter taky vyresil volanim externiho prikazu... > Ja bych to vynechal uplne a nastaveni resil nejako pres API. Grafickeho= =20 > by tam podle me nemelo byt nic, prave kvuli teto rozdilnosti pouzitych > toolkitu. OK, domluveno. > Implementaci do programu bych nechal na kazdem, at si to udela po svem.= =20 > User vubec nemusi vedet, ze tam nejaky plugin ma a podle > me ho to ani moc nezajima. Hlavne ze tam ta funkce je.... > Informace o pluginu bych pak vypisoval pres prikaz=20 > program --help-nazev_pluginu. To je docela zajimave, kazdopadne bych tam asi dal nejakou funkci ktera bude vracet retezec, aby se daly z kazdeho pluginu zobrazit nejaky informace - about a tak... ;) Takze tim padem pokud uz nikdo nic nema k tehle zevrubne strukture, asi zacnu psat cast 2. primo s navrhem API. ---- Tom=E1=B9 B=BEatek |
|
From: <bla...@se...> - 2004-02-17 07:54:11
|
Omouvam se za zpozdeni, nebot jsem byl tri dny v praci :-( > Takze: kazdy VFS modul by mel byt jako samostatny plugin (klasicka > .so), napsany s presne definovanym API. Pluginy by se mely natahovat > pri startu programu, kazdy plugin by mel obsahovat funkce, ktere > nejakym zpusobem vrati moznosti pluginu Nejlepe asi pres writeln() > Bylo by asi nejlepsi, kdyby vsechny funkce v pluginu byly > implementovane primo pomoci kodu nebo volanim nejakych funkci > externich knihoven, rozhodne bych nechtel postavit celej plugin na > volani nejakeho programu (treba tar) - kvuli problemum s tuhnutim > forku na ktere jsme uz skoro kazdy nejakym zpusobem narazili. To by bylo moudre, nicmene v tomto jsem jeste dost veci neprekousl. Nepodarilo se mi rozchodit ani mount() pres libc. Budto to nefunguje nebo jsem to nepochopil, tak jsem zvolil cestu nejmensiho odporu pres externi prikaz(docasne). > > Dalsi moje idea je takova, ze by kazdej plugin moh mit svoje nastaveni > - dialog, ktery by se volal primo z pluginu a dalo se v nem nastavit > chovani pluginu (potreba hlavne pro nastaveni FTP a dalsich browseru). > Tady nastava jeden problem a sice nekompatibilita s window toolkitama > (GTK vs. QT) - bud by se to muselo resit nejak abstraktneji nebo > dvojitym kodem (to by bylo pak ale spatne z hlediska udrzby). Tohle > bych prozatim odlozil. Ja bych to vynechal uplne a nastaveni resil nejako pres API. Grafickeho by tam podle me nemelo byt nic, prave kvuli teto rozdilnosti pouzitych toolkitu. > > Moje predstava o implementaci do programu je skrz menu Plugins, kde by > kazdy plugin mel vlastni submenu a tam svoji konfiguraci, svuj about a > svoje funkce... Tusimze Servant Salamander to tak ma - musim se na to > mrknout, pod linxuem to nejede :( > Implementaci do programu bych nechal na kazdem, at si to udela po svem. User vubec nemusi vedet, ze tam nejaky plugin ma a podle me ho to ani moc nezajima. Hlavne ze tam ta funkce je.... Informace o pluginu bych pak vypisoval pres prikaz program --help-nazev_pluginu. > Ufff.... no, tohle je zatim zacatek, pak se budem muset jeste > dohodnout presne na tom API. > Ocekavam od vas komentare :) taky uff... Jdu si koupit tlusty knihy.... > ---- > Tomáš Bžatek > Jiri Blahovsky |
|
From: Tomas B. <sou...@bz...> - 2004-02-15 11:13:04
|
On Sun, 2004-02-15 at 08:45, Radek Cervinka wrote: > jaky je z pohledu programu rozdil mezi vylistovanim archivu a vylistova= nim > adresare na ftp? Podle mne se to schovat pod jedno rozhrani Rozdil tam nebude skoro zadny, bude se pouzivat stejne VFS API, ale rozdil bude v tom, jak se to bude volat (nekde z menu/tlacitka/klavesove zkratky - pricemz by se mel objevit asi nejakej Site Manager), taky v tom, ze asi budou vyskakovat nejake okynka (treba s heslem) a taky bych chtel, aby u FTP byl videt nekde log (idealne zadokovany v hlavnim okne nad/pod panelama). Tyhle veci u archivu pravdepodobne nebudou. > > Dalsi moje idea je takova, ze by kazdej plugin moh mit svoje nastaven= i -=20 > > dialog, ktery by se volal primo z pluginu a dalo se v nem nastavit=20 > > chovani pluginu (potreba hlavne pro nastaveni FTP a dalsich browseru)= .=20 > Ja si nemylim, ze by ta konfigurace byla nezbytna, kazdopadne by se to = dalo > resit v ramci programu a pak vysledek predat pouze pres API do plugginu= . Tohle bych zatim neresil, dodelat se to da vzdycky, ale to predavani parametru do pluginu bude asi nejlepsi... > > Moje predstava o implementaci do programu je skrz menu Plugins, kde b= y=20 > > kazdy plugin mel vlastni submenu a tam svoji konfiguraci, svuj about = a=20 > > svoje funkce... Tusimze Servant Salamander to tak ma - musim se na to= =20 > > mrknout, pod linxuem to nejede :( >=20 > To je snad zalezitosti toho programu a ne VFS? To bylo jen pro inspiraci :) Ale zas bych chtel, aby v programu nebyly prebytecne kusy kodu patrici k pluginum, pokud tam nebudou - proto jsem chtel ty formulare nacpat do pluginu. Jak jsem jiz psal, tohle bych zatim neresil, v prvni fazi stejne musime zprovoznit zakladni archivy. > ja nekdy pozivam call back funkci, kde se pri inicializaci predava poin= ter=20 > na logovaci funkci, a pak se vola jen tato, a co si s tim hlavni progra= m=20 > udela, to uz je jedno Logovani ja zatim resim vypsanim textu primo na konzoli (writeln), ale tohle je dobrej napad, to bysme mohli udelat (pokud uz to neni primo v tom tvym VFS API). > me se treba u rpm libi, kdyz se muzu podivat jen "dovnitr" tj. na infor= mace > nebo kdyz si muzu rozbalit jen jeden soubor Jo, u rpm se to docela hodi, mc to ma taky tak reseni, ale v tar-gz/bz2 nic takoveho neni, jenom jeden soubor. Nevim jak je na tom deb, asi podobne, ja pouzivam gentoo takze vsechny tyhle problemy se mne netykaji ;-) > Za tim to vcelku odpovida VFS Seksi commanderu :), jen neco pridat, nec= o=20 > ubrat :) No, a to jsme jeste nezacali probirat primo definice funkci - to bude druhy krok az s timhle budeme vsihni souhlasit. ---- Tom=E1=B9 B=BEatek |
|
From: Tomas B. <sou...@bz...> - 2004-02-15 10:49:37
|
Byla spatne nastavena hlavicka Reply-To v mailing listu, ted uz by to melo byt vporadku, omlouvam se, takze preposilam mail od Radka ktery by mel byt spravne v mailinglistu. -----Forwarded Message----- From: Radek Cervinka <rad...@ce...> To: sou...@bz... Subject: Re: [Tuxcmd-dev-vfs] Koncepce VFS - cast 1. Date: Sun, 15 Feb 2004 08:45:12 +0100 Tomas Bzatek wrote: > Takze: kazdy VFS modul by mel byt jako samostatny plugin (klasicka .so), > napsany s presne definovanym API. Pluginy by se mely natahovat pri > startu programu, kazdy plugin by mel obsahovat funkce, ktere nejakym > zpusobem vrati moznosti pluginu > - tedy hlavne co to je za typ pluginu (jestli archivovy, nebo nejaky > browser - treba FTP, SMB atd...) jaky je z pohledu programu rozdil mezi vylistovanim archivu a vylistovanim adresare na ftp? Podle mne se to schovat pod jedno rozhrani > - registrovane pripony (pokud je to archivovy) Ja > - ktere operace se s nim daji provadet/ktere jsou implementovany > (vetsina pluginu bude zpocatku read-only, nebudou mit nektere funkce). Ja > Bylo by asi nejlepsi, kdyby vsechny funkce v pluginu byly implementovane > primo pomoci kodu nebo volanim nejakych funkci externich knihoven, > rozhodne bych nechtel postavit celej plugin na volani nejakeho programu > (treba tar) - kvuli problemum s tuhnutim forku na ktere jsme uz skoro > kazdy nejakym zpusobem narazili. souhlasim, i kdyz sem na to nenarazil > Dalsi moje idea je takova, ze by kazdej plugin moh mit svoje nastaveni - > dialog, ktery by se volal primo z pluginu a dalo se v nem nastavit > chovani pluginu (potreba hlavne pro nastaveni FTP a dalsich browseru). Ja si nemylim, ze by ta konfigurace byla nezbytna, kazdopadne by se to dalo resit v ramci programu a pak vysledek predat pouze pres API do plugginu. > Tady nastava jeden problem a sice nekompatibilita s window toolkitama > (GTK vs. QT) - bud by se to muselo resit nejak abstraktneji nebo > dvojitym kodem (to by bylo pak ale spatne z hlediska udrzby). Tohle bych > prozatim odlozil. Ja bych fakt GUI do totho netahal, ve vysledku by to melo spoustu problemu. > Moje predstava o implementaci do programu je skrz menu Plugins, kde by > kazdy plugin mel vlastni submenu a tam svoji konfiguraci, svuj about a > svoje funkce... Tusimze Servant Salamander to tak ma - musim se na to > mrknout, pod linxuem to nejede :( To je snad zalezitosti toho programu a ne VFS? > Problemy: > - musi se zajistit API a ABI kompatibilita mezi ruznymi programovacimi > jazyky, takze nepouzivat zadne specialni datove typy a vsechny funkce > oznacovat jako cdecl (to bude asi nejlepsi). Pak muze nekdo vyvijet > plugin v Cecku a normalne ho pouzit v Pascalovskem programu. a naopak > - pokud bude plugin slinkovan (dynamicky) s nejakou dalsi externi > knihovnou, ktera nebude v okamziku natahovani dostupna, tak by bylo > dobre kdyby se nekde vypsalo co tomu presne chybi (soubor). I kdyz tohle > se da vyresit zavolanim ldd... (chcu to hlavne kvuli ladeni). ja nekdy pozivam call back funkci, kde se pri inicializaci predava pointer na logovaci funkci, a pak se vola jen tato, a co si s tim hlavni program udela, to uz je jedno > - zajimalo by mne, jak se budou resit problemy s dvojitym balenim - > myslim tim tar+gz/tar+bz2 - zpocatku asi nijak, pozdeji by se pri > otevirani archivu provedlo rovnou dvoji rozpakovani - nejlepe bez > zadneho pomocneho souboru (prip. by se to dalo nejak nastavit nebo brat > nejaky limit velikosti archivu) me se treba u rpm libi, kdyz se muzu podivat jen "dovnitr" tj. na informace nebo kdyz si muzu rozbalit jen jeden soubor > > Ufff.... no, tohle je zatim zacatek, pak se budem muset jeste dohodnout > presne na tom API. Za tim to vcelku odpovida VFS Seksi commanderu :), jen neco pridat, neco ubrat :) Radek |
|
From: Tomas B. <sou...@bz...> - 2004-02-14 15:21:52
|
Vazeni, ted vam tady napisu moji predstavu o tom, jak by VFS melo vypadat. Asi to rozdelim do vic casti, prvni spis obecne a pak teprve do detailu. Rad bych abyste se k tomu vyjadrili, abysme to mohli vsechno poradne probrat a teprve pak zacali implemntovat. Takze: kazdy VFS modul by mel byt jako samostatny plugin (klasicka .so), napsany s presne definovanym API. Pluginy by se mely natahovat pri startu programu, kazdy plugin by mel obsahovat funkce, ktere nejakym zpusobem vrati moznosti pluginu=20 - tedy hlavne co to je za typ pluginu (jestli archivovy, nebo nejaky browser - treba FTP, SMB atd...) - registrovane pripony (pokud je to archivovy) - ktere operace se s nim daji provadet/ktere jsou implementovany (vetsina pluginu bude zpocatku read-only, nebudou mit nektere funkce). Bylo by asi nejlepsi, kdyby vsechny funkce v pluginu byly implementovane primo pomoci kodu nebo volanim nejakych funkci externich knihoven, rozhodne bych nechtel postavit celej plugin na volani nejakeho programu (treba tar) - kvuli problemum s tuhnutim forku na ktere jsme uz skoro kazdy nejakym zpusobem narazili. Dalsi moje idea je takova, ze by kazdej plugin moh mit svoje nastaveni - dialog, ktery by se volal primo z pluginu a dalo se v nem nastavit chovani pluginu (potreba hlavne pro nastaveni FTP a dalsich browseru). Tady nastava jeden problem a sice nekompatibilita s window toolkitama (GTK vs. QT) - bud by se to muselo resit nejak abstraktneji nebo dvojitym kodem (to by bylo pak ale spatne z hlediska udrzby). Tohle bych prozatim odlozil. Moje predstava o implementaci do programu je skrz menu Plugins, kde by kazdy plugin mel vlastni submenu a tam svoji konfiguraci, svuj about a svoje funkce... Tusimze Servant Salamander to tak ma - musim se na to mrknout, pod linxuem to nejede :( Problemy: - musi se zajistit API a ABI kompatibilita mezi ruznymi programovacimi jazyky, takze nepouzivat zadne specialni datove typy a vsechny funkce oznacovat jako cdecl (to bude asi nejlepsi). Pak muze nekdo vyvijet plugin v Cecku a normalne ho pouzit v Pascalovskem programu. - pokud bude plugin slinkovan (dynamicky) s nejakou dalsi externi knihovnou, ktera nebude v okamziku natahovani dostupna, tak by bylo dobre kdyby se nekde vypsalo co tomu presne chybi (soubor). I kdyz tohle se da vyresit zavolanim ldd... (chcu to hlavne kvuli ladeni). - zajimalo by mne, jak se budou resit problemy s dvojitym balenim - myslim tim tar+gz/tar+bz2 - zpocatku asi nijak, pozdeji by se pri otevirani archivu provedlo rovnou dvoji rozpakovani - nejlepe bez zadneho pomocneho souboru (prip. by se to dalo nejak nastavit nebo brat nejaky limit velikosti archivu) Ufff.... no, tohle je zatim zacatek, pak se budem muset jeste dohodnout presne na tom API. Ocekavam od vas komentare :) ---- Tom=E1=B9 B=BEatek |
|
From: Tomas B. <sou...@bz...> - 2004-02-13 11:06:07
|
Toto je testovaci mejl, jelikoz nemam posledni dobou moc sympatii k SourceForgi, tak zkousim, jestli to vubec dojde... Jinak je patek 13. takze je taky mozny ze to vubec chodit nebude :( ---- Tom=E1=B9 B=BEatek |
