???.txt

[ide.ne.irj at freemail.hu]

Thus spake Andras Tantos:

> Egyenlore ezeket az extra funkciokat meg eleg keves program hasznalja, leven 
> a FAT kompatibilitas meg mindig fontos. De pl. az extra stream-ekben lehet 
> biztonsagi informaciot, cache-elt elofeldolgozott adatokat, hasznalati 
> jellemzoket, ilyesmit tartani. Az elonye a megoldasnak, hogy az osszes 
> stream a fajl-al egyut mozog, de ha egy program csak a 'primary stream'-et 
> kezeli, akkor sincs belole problema.

Ez valoban zsenialisan hangzik, de talalkoztal mar MAC alatt ilyesmivel?
A gyakorlatban inkabb csak a nyug van vele, kulonosen, ha a fajlokat mas
platformon is kezelni szeretned. Ha az osszes adat a tobbi streamben mind
nyugodtan torolheto, mert a fo streambol legalabb a filet kezelni tudo
progi barmikor elo tudja allitani (pl preview), akkor nem biztos hogy gaz,
de miert nem lenne jo az, hogy a fajlon kivul egy kulon cache-ben tarolna
az ilyesmit a rendszer, vagy barmi egyeb megoldas?
Mexoktuk, hogy a kulonbozo platformokon futo programok adatszerkezetei
ritkan kompatibilisek egymassal, de kuzdunk hogy minel kevesebb legyen a
problema. Mert ugye az adatok programfuggetlensege meg a programok
hardverfuggetlensegenel is fontosabb.
Ez a tobb stream egy fajlban pedig magat a file fogalmat teszi
inkompatibilisse a kulonbozo architekturak kozott.
En speciel nem orulok neki, nem is lehet veletlen hogy nem terjed
futotuzkent...
Ha sok penzem lenne, es egy nagy szoftverceget iranyitanek, lehet hogy
kib at xasbol olyan filesystemet csinalnek, melyben a fajlokon belul nem csak
tobb stream, hanem akar ujabb fajlok es konyvtarak is lehetnek :))
Na milyen otlet? Nem lenne semmivel sem kompatibilis, izzadhatna a
kunkorrencia...
Vegul is errol van szo. Ez az egesz tobbstreames dolog egy apro kis
patchhel minden rendszeren implementalhato lenne, csak a kovetkezot kene
csinalni: az "aaa\bbb\ccc.txt" szerkezetu path-bol at kene kovertalni
minden elerest "aaa\bbb\ccc.txt\1" szerkezetuve. Lenne nehany specialis
uj fuggveny, melyek el tudnak erni az uj streameket, melyek az
"aaa\bbb\ccc.txt\2", "aaa\bbb\ccc.txt\3" stb.. fajlokra mutatnanak.
A struktura ezzel ekvivalens, semmi varazslat nincs benne.
Na de nezzuk, hogy mennyire valtana meg a vilagot:

> - Mondjuk egy make-szeru program itt tarolhatna az elofeldolgozott fuggoseg 
> informaciokat, azaz, hogy mikor kell leforditani egy fajlt es mikor nem

Logikailag nem all ossze, pontosan melyik fajlnak melyik streamjeben
tarolnad ezt, es miert pont ott? Szerintem erre tok jo a jelenlegi
megoldas, hogy van egy kulon fajl erre...
Egyebkent megnezem mikor lesz a C programozok kedveert kulon filesystem :)

> - Egy verzio-management program tarolhatna itt a regebbi valtozatok 
> diff-jeit. Igy egy csomo muvelet lokalisan elvegezheto lenne - kb. ugy, mint 
> a SubVersion csinalja, de nem kellene hozza az a rengeteg rejetett mappa

Ez is egy rendkivul komoly problema :) Probald elmeselni egy
felhasznalonak, aki nem programozik.
A VMS megtart minden verziot a fajlokrol, kivalo lenne erre, de nem
terjedt el. Ez sem fog :)

> - Egy java-szeru futtato kornyezet tarolhatna az elo-forditott, vagy 
> teljesen leforditott binaris kodot a byte-kod mellett

Es az miert jo? A Java-ban, mint megtudtuk, az a poen, hogy konkretan
tudja a fordito hogy milyen rendszeren fut, es ezert futas kozben tud
optimalizalgatni a progin. Mar megtargyaltuk hogy milyen sikerrel :),
de ez meg ezt az elvi elonyet is kiherelne :))
Valamint nem vagyok biztos benne hogy lehetseges ez. Az a kod ugy fordul
le, hogy a konkretan megkapott cimek bele vannak drotozva a progiba, a
legkozelebbi inditaskor termeszetesen minden mashol lesz, az eloforditott
kod tuti eldobhato, es lehet elolrol kezdeni.

> - Egy rights-management program tarolhatna egy alternativ stream-ben a 
> digitalis alairasokat, es hozzaferesi jogokat. Ez igy minden tipusu fajlra 
> alkalmazhato lenne, nem kellene a formatumokat megvaltoztatni

Eddig ez az elso peldad, ahol valoban fontos, a file-bol nem reprodukalhato
adatokat szeretnel mellette tarolni. Itt jon a kovetkezo ervem: mi tortenik
ezzel a fajllal amikor megmerited egy ilyen tobb streames fajlokat nem
ismero rendszerben, mondjuk kenyszerusegbol? Adat elvesz -> sanyi.

> - Egy back-up program tarolhatna az utolso mentesre vonatkozo informaciokat 
> itt, es nem csak egy bitnyi informacioja lenne arrol, hogy mi tortent ezzel 
> a fajlal backup ugyben

Ez megint logikai bukfenc :) A backup progi nyilvan eleve tobbstreames
fajlokat archivalna, nem? Mindegyikhez hozzatenne meg egy streamet?
Semmi ertelme.

> - Egy kepfeldolgozo program tarolhatna kulonbozo felbontasu, vagy formatumu 
> verziokat egy kepbol a kulonbozo stream-ekben, es azt venne eppen elo, 
> amelyikre az adott megjeleniteshez vagy muvelethez 
> (web/full-screen/print/fax/e-mail/thumbnail/icon) szuksege lenne

Mar feltalaltak a progressziv JPEG-et, ami ugyanezt tudja, es nem kell
feleslegesen (esetleg tobb!) preview fajlt eltarolni.
A tomoritesnek es a bonyolult file-szerkezetnek az a lenyege, hogy
kevesebb adatot kelljen tarolni. Ha te tobbfele, kulonbozo felbontasu
tomoritett fajlt akarsz tarolni, akkor mar egyszerubb az egeszet
tomorites nelkul egyszer letarolni, akkor preview sem kell...

> - Egy file manager tarolhatna itt 'preview' adatokat, mondjuk egy dokumentum 
> elso oldalanak a kepet, es ezt akkor is meg tudna jeleniteni, ha a fajl 
> kezelesehez szukseges program (mondjuk AutoCAD) epp nincs a gepen telepitve

Az otlet maga jo, sokkal egyszerubben is megvalosithato, a file fogalom
atszerkesztese es kiterjesztese nelkul.
Nehany lehetoseg: ikonba berakni (kepeknel amigan megoldottak), kulon
valami dokumentum cache, esetleg a fajlokban egy szabvanyos chunk, mint
mondjuk a resource, stb... Minek ehhez kulon stream?

> - Egy tomorito program tarolhatan minden egyes tomoritett fajlt kulon 
> stream-ben, es a main-stream-ben csak az index-et, ezzel gyors 'random' 
> elerest lehetove teve a tomoritett tartalomhoz.

Ez sem valami jo otlet ugyan, de azert tetszik :)
A RAR (amigan az LZX) ota nem kulon tomoritodnek a fajlok, hanem blokkokban.
Azaz van valamekkora blokkmerete a tomoritonek, azt feltolti tobb fajllal,
majd egyutt tomoriti oket. A kisebb fajlokbol sok elfer, a nagyok tobb
blokkba atnyulnak. Na ezt hogy rakod be tobb streambe?
Csak a tomoritesi hatekonysag csokkentesevel lehetne megoldani, tok
felesleges az egesz.
Termeszetesen nem is lenne semmivel randomabb mint amikor a tomorito eri
el a fajlokat az archivban. De megis tetszik a megoldas, mert nem kene
minden tomorito programozonak kitalalni es lekodolni a sajat file
kezeleset, mert a filesystemeket pont erre talaltak ki, valoszinuleg
sokkal optimalisabb megoldas egy profi FS, mint a sajat otletszeru
ganyolasok. De ezt is kitalaltak mar: tar.
Valamint itt van a windoz registry... Ugyanez a feladat, megsem biztak
a filesystemre, inkabb kokanyolnak egy sokmegas binaris fajlt. Miert?
Nem tudom. De amig ilyenek a rendszerek, szerintem ne almodjunk, hogy a
programozok kedveert kitalalnak egy sajat fajlrendszert, ami mar a file
fogalom szintjen sem kompatibilis a jelenlegi megoldasokkal.

> API hivasokat hasznal (a 'W' vegueket, mint CreateFileW stb.) akkor nem 
> lehet gondja a kodlapokkal, mert a Unicode nem ismeri oket. Az egyetlen gond 
> akkor lehet, ha valamilyen Unicode string-et ASCII-ra, vagy meg inkabb 
> multibyte-ra akar konvertalni, de erre csak akkor van (lehet) szuksege, ha 
> nem teljesen Unicode-ban irodott, vagy nem kizarolag Unicode API-okat 
> hasznal.

Persze, logikus. De tud valaki olyan rendszert, mely 100% unicode
alapon muxik, sehol sem kell konvertalni, es nem hibazik?
En nem. Mindig van valami szopas. Talan ha csak windozt, es csak az ujabb
M$ termekek egy reszet hasznalja az ember. Eselytelen...

> Tantos Andras

-- 
Valenta Ferenc <vf at elte.hu>   Visit me at http://ludens.elte.h u/~vf/
"Adjatok nekem eleg nagy stacket, es kiforditom a kernelt a 4 sarkabol!"