???.txt

[Andras Tantos]

>> Ja, nem rossz gondolat :-). Amugy, ha nem is a fajlnevbe, de alternative
>> stream-ekbe sok mindent be lehet rakni NTFS alatt. Ott egy fajlhoz 
>> ugyanis
>> nem csak egy stream tartozhat, mint DOS, Unix stb. alatt, vagy ketto, 
>> mint
>> MacOS alatt, hanem akarhany. Szoval hajra! Tudtommal volt is mar virus,
>> amelyik igy rejtette el magat.
>
> Ennek lehet tudni hogy mi az ertelme? Miert jo (a virusokon kivul) hogy
> egy fajlban tobb adat is lehet? Kinek jutott ez az eszebe, es milyen
> problemat velt megoldani vele?
> Sima masolaskor hogy viselkedik egy ilyen file, exploderben hogy nez ki?

Pontosan nem tudom az okat, de az a velemenyem, hogy az NTFS-be a Mac 
kompatibilitas miatt kerult bele - az NT szerver hasznalhato Mac-es 
halozatban fajlszervernek. A Mac a masodik stream-et 'resource stream'-nek 
nevezi, es ebben olyan infokat tarol, hogy milyen programmal kell megnyitni 
a fajlt, es hasonlok. De nem vagyok nagy tudora a Mac-es dolgoknak, lehet, 
hogy tevedek.

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.

Egy-ket pelda a felhasznalasra:
- Mondjuk egy make-szeru program itt tarolhatna az elofeldolgozott fuggoseg 
informaciokat, azaz, hogy mikor kell leforditani egy fajlt es mikor nem
- 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
- Egy java-szeru futtato kornyezet tarolhatna az elo-forditott, vagy 
teljesen leforditott binaris kodot a byte-kod mellett
- 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
- 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
- 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
- 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
- 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.

Most hirtelen ennyi jut eszembe...

>
>> Ha a hibauzenet valami ilyesmire hivatkozott, akkor a problema ott volt,
>> hogy a program nem volt Unicode-ban irva. Vagy legalabbis nem teljes
>> egeszeben. Az Explorer meg azert tudja kezelni, mert abban korrekt a 
>> Unicode
>> tamogatas.
>
> Amennyiben a FAT32 unicode korrektnek nevezheto.

En az NTFS-rol beszeltem, mert ugy ertettem, hogy az eredeti kerdes is 
NTFS-rol szolt. De raadasul az Explorer-nek semmi koze a faljrendszerhez. 
Amit irtam mindossze arra vonatkozott, hogy ha egy program kizarolag Unicode 
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.

Udv,
Tantos Andras