???.txt

[Andras Tantos]

Hali!

>> 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?

Nem, mert nem hasznaltam Mac-et. De tudtommal ott ez a standard, igy minden 
program hasznalja. Igaz (megintcsak tudtommal) a 'secodary stream' funkcioja 
kotott.

> 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?

Rendszertelenseg. En speciel gyulolom a 'thumb.db' fajlokat, amiket az MS 
kepnezegetoje a konyvtarakba pakol, vagy a registry-t, ahova a program 
beallitasok kerulnek, vagy a GAC-et, bar errol valoszinuleg nem tudsz, ahova 
a .NET applikaciok cache-elt, leforditott valtozatai kerulnek. Annak, hogy 
ezeket egyut tarolod, az a legnagyobb elonye, hogy a masodlagos informaciok 
*mindig* egyut mozognak az elsodlegessel. Nem problema, hogy hogy talalod 
meg ezeket az informaciokat egy 'move' vagy 'rename' utan, es plane nem 
problema, hogy hogyan torlod egy 'delete' utan.

> 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.

Nem ilyen egyszeru, de kb.

> 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 :)

Ez nem igy kerdes: mikor fogjak a C programozok kihasznalni a meglevo 
lehetosegeket. De amire gondolok, pl: minden C fajl egy alternativ 
stream-jeben eltarolod a front-end kimenetet, es azt, hogy milyen fajlok 
valtozasa eseten kell ujraforditani. A forditas soran igy gyorsan 
ellenorizheto, hogy az adott fajlt ujra kell-e forditani, vagy sem. De 
lehetne itt tarolni a back-end kimenetet is (object fajl, tradicionalisan). 
Igy egy forditoval integralt 'make', kb. ugy, mint ahogy a Turbo Pascal 
csinalta, sokkal gyorsabban meg tudna talalni az ujraforditando fajlok 
koret. Raadasul a forditasi konyvtar nem lenne osszeszemetelve .obj, meg 
egyeb fajlokkal.

De nem muszaj szeretni ezt az otletet. Csak egy lehetoseg, amit felvetettem.

>> - 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.

Oh, nagyon egyszeru: nem egyszer tortent meg, hogy csaladtagok veletlenul 
toroltek ezt-azt egy-egy fajlbol, majd elkeseredetten hivtak, hogy most 
akkor mi legyen. En meg szettartam a karjaimat, hogy most mar semmi. Igy meg 
azt lehetne mondani, hogy 'menj vissza ket verziot, es ott lesz'.

En speciel azt hiszem, hogy a verzio kontrol es backup rendkivul hasonlo 
dolgok, es mindenkinek nagyon fontosak lennenek. De egeszen addig, amig 
nincs jo OS tamogatas hozza (akar Unix, akar Windows, akar MacOS, akar 
AmigaOS, a te kedvenced), addig nem fogjak hasznalni, es nem fog elterjedni. 
Egy atlagos felhasznalot tapasztalatom szerint nem a HDD halalatol, hanem a 
sajat hulyesegetol kell megvedeni, es ezt meg lehet tenni autmatikusan. Ja, 
es azt elmagyarazni, hogy egy verzio, az egy 'biztonsagi mentes, egy 
cimkevel, hogy emlekezz ra, hogy mi is van benne' nem olyan nagy ugy.

> A VMS megtart minden verziot a fajlokrol, kivalo lenne erre, de nem
> terjedt el. Ez sem fog :)

A VMS megoldasa is eleg jo, egyebkent linux alatt is bekapcsolhato ez a 
viselkedes. A problema az, hogy nem tomorit, es nem diff-eket tarol. Azaz 
zabalja a lemezt.

>> - 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 :))

De ez nem azt jelenti, hogy az elso futtatas utan, amikor az adott gepre 
megtortent a forditas, ennek az eredmenyet nem lenne jo elmenteni, hogy 
legkozelebb mar csak elo kelljen huzni. Nem tudom a Java csinal-e ilyet, a 
.NET igen. GAC-nek hivjak ezt a cache-t, de sok problema van vele, tobbek 
kozott az, hogy hogyan azonositod be, hogy melyik cache-elt adat melyik 
fajlhoz tartozott.

> 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.

Ez megvalositas kerdese, nem szuksegszeru. Es amiota van VMM, minden 
processz a sajat dedikalt cimtartomanyaban fut, es eleve fix cimekre van 
linkelve, legalabbis Windows alatt.

>> - 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.

Akkor nem tudod tobbe megnyitni. Adott esetben az OS meg is teheti, hogy nem 
engedi ilyen mediara masolni a fajlt, vagy azt csak titkositva teheted meg, 
ugy, hogy csak ugyanazon a gepen tudod visszaolvasni. De nem ertek a DRM 
technologiakhoz, ugyhogy ebbe ne menjunk bele.

>> - 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.

Leven tetszoleges szamu stream-ed lehet, ezert ez nem problema. Van egy 
stream, amit a backup program hasznal. Ennek van egy egyedi azonositoja, ezt 
olvassa, irja, a tobbit meg arhivalja. Egy fajl akkor valtozik a backup 
program szempontjabol (es szinte minden szempontbol) ha legalabb egy 
stream-je valtozott.

>> - 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...

Nem erted: pont az lenne a poen, hogy ne kelljen a fajlformatumot 
valtoztanti. A kezelo progi egyszer belenez az eredeti stream-be, majd a 
sajat szaja ize szerinti formatumra konvertalt verziot elrakja egy 
alternativ stream-be. Ha legkozelebb szuksege van ra, csak elokapja. Egy 
nagy kepnel a konverzio jo sokaig tarthat - foleg, ha tomorites nelkul 
tarolod, es ki kell varni amig a vinyo mind a 150MB-hoz tartozo szektort 
vegig nyalazza.

>> - 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?

Itt is, mint mashol a problema: a cache-ben tarolt adatok osszekotese az 
eredeti fajl-al, a valtozasok kovetese, es foleg, a cache uritese torles 
utan, gyorsan, hatekonyan, es cache atfesulese (garbage collection) nelkul.

> Valamint itt van a windoz registry... Ugyanez a feladat, megsem biztak
> a filesystemre, inkabb kokanyolnak egy sokmegas binaris fajlt. Miert?
> Nem tudom.

Ezt en sem. Pontosabban, a registry egy jo otlet rossz megvalositasa. A jo 
otlet: ahelyett, hogy minden program es programozo maga oldana meg a 
beallitasok tarolasat, es ujra es ujra feltalalna a spanyol viaszt, adjunk 
ehhez nehany fuggvenyt OS szinten, amivel ez egysegesen es egyszeruen 
megoldhato. Es ha mar ezt megtettuk, automatikusan megoldhato egy csomo 
minden mas is, anelkul, hogy a programok errol tudnanak. Lehet szindi pl. a 
regedit-et, de Linux alatt meg minden beallitas fajl formatuma mas, az 
annyival jobb?

A megvalositas persze eleg szar lett, es ebben a legnagyobb bunos a COM/OLE, 
azaz az osztott binaris komponensek elterjedese.

>> 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...

Nem, de errol nem a unicode, inkabb a lusta programozok tehetnek.

Udv,
Tantos Andras