Adatok az adatokról

Ha most nem jut eszedbe, mit jelent a Send Windows Friendly Attachments jelölönégyzet a Mail levelezõ-programban, vagy sejtésed sincs, mire jó a FixupResourceForks parancs a CoreServices mappában, akkor remélem elég kíváncsivá tettelek, ami kitart az írás végéig. Kávé, tea, parancssor, mehetünk is.

Szerencsére nem vagyunk egyedül! A mindennapi Macintosh használat során más platformokkal is kell kommunikálni, ez az esetek nagytöbbségében fájl csere-berét jelent. Ezeket az adatok valamilyen módon tárolódnak az adott fájlrendszerben, mégpedig nem csak a tiszta adatok, hanem a hozzá kapcsolódó adatok is. Õk a metaadatok.

Mik is azok a metaadatok? Adatok az adatról. Olyan adatok, amelyek szoros kapcsolatban állnak az eredeti adattal. A számítógépiparral kapcsolatban a metaadat legáltalánosabb alkalmazási területe a fájlrendszerekben található. A fájlok adatokat tartalmaznak, amelyek meghatározott mennyiségû metaadatot tartalmaznak önmagukról. A metaadat legalapvetõbb tulajdonsága, hogy megkülönböztethetõ az adattól. Tehát nem maga az adat, hanem adat az adatról, ami szorosan kapcsolódik hozzá.

Egy egyszerû fogalom, de meglepõen szerteágazó, vitatott témakör. A Mac OS X megjelenésével a téma különösen aktuálissá vált a Mac platform jövõje szempontjából.

Mirõl lesz és mirõl nem lesz szó ebben az írásban?. A cikk a metadata alapvetõ fogalmairól szól, függetlenül a megvalósításától. Biztos sokat tudsz a számítógépekrõl, de most próbáld meg az elméleti elgondolásokat anélkül olvasni, hogy következtetéseket, vagy párhuzamokat vonnál le az eddigi tudásod alapján.

Ahhoz, hogy bemutassuk a metaadatot, készítsünk el egy fájlt elméletben, amelynek megvizsgáljuk a metaadatait. Metaadat nélkül ez a fájl csak egy adathalmaz, egy rakás bit, semmi több. Milyen adatokat lehet ehhez a bithalmazhoz csatolni, amelyek segítenek neked az azonosításában?

Elõször is talán a legfontosabb a fájl neve. Ez minden kétséget kizárólag egy alapvetõ információ. A fájl elérésekor a fájlnévnek kritikus szerepe van a hagyományos fájlrendszerekben. Ha nem tudod a fájl nevét, kevés az esélye, hogy megtalálod, ugye?

A fájl tárolási helye
Csak a fájlnév nem elegendõ, hogy minden kétséget kizáróan az általad keresett fájlt találd meg a gépeden. A fájl elérési helye a számítógép és a benne lévõ merevlemez nevébõl és a fájlt tároló könyvtárszerkezetbõl alkotott információ adott kombinációja. Egyértelmûen megadhatsz egy fájlt, ha a nevét és a fájl tárolási helyét egy azonosítóban tárolod, amelyet gyakran a fájl elérési útjának (file path) neveznek. Tehát keresheted a "Rózsaszín Párduc" képet a saját mappád képmappájában, ezzel megadtad a fájl nevét és az õt tartalmazó mappa nevét is. Ami itt fontos, hogy a fájl tárolási helye is a fájlról szóló metaadat egy része, tehát nem az õt tartalmazó mappához, hanem az adott bithalmazhoz tartozik. Másik fontos tulajdonsága ennek a metaadatnak, hogy nélküle nem lehetséges a fájl olvasása és írása, nélkülözhetetlen a fájlban tárolt adatok eléréséhez.

A fájl típus
A fájl típusa, azaz a fájlban található adat fajtája. Ez arra a kérdésre felel, hogy milyen adatot tartalmaz a fájl? Mi az az adott fájl? Egy kép, szöveg vagy mozifilm? Ezt a fájl tartalomtípusának, vagy egyszerûen a típusának is nevezik. A részletességet figyelembe véve az alapvetõ besorolás mellett, mint a kép, hang, videó és szöveg, a fájlnak adott formátuma is lehet, mint a TIFF, AIFF, MPEG2, TEXT, illetve léteznek adott formátumok még pontosabb besorolásai, mint a réteges TIFF, beágyazott képet tartalmazó rtf szöveg. Próbáld ki TextEditben a címsorban szereplõ ikont is behúzhatod a dokumentumba!

A fájl mérete
A fájlban található adatnak mindenképp van mérete, még ha az nulla is. Ez megint furcsának hangzik, de ha egy üres szövegfájlra gondolsz, amibe egy sort nem írtál, de már elnevezted, elmentetted az íróasztalra, ezáltal létrehoztad, piros címkét ragasztottál rá és az általad elkészített gyönyörû, 128x128 képpontos ikont adtál neki, tehát hozzá kapcsolódó adatokkal, azaz metaadatokkal láttad el. A fájl méretének az ismerete, mint a név és a tárolási hely szintén nélkülözhetetlen. Képzelj el egy olyan fájlrendszert, ahol ismeretlen méretûek a fájlok!

A fájl dátumai
Ha ismered ezeket az adatoka,t nagyon sok hasznos információhoz juthatsz a fájllal kapcsolatban: mikor hozták létre - a kíváncsi Almalap innen tudja, mikor is kezdtem hozzá ennek a cikknek a megírásához -, mikor történt a legutóbbi adatmódosítás, mikor változtatták meg a fájl nevét, azaz a metaadat változtatásokat is tárolva vannak, mikor történt a legutolsó hozzáférés, ami nem feltétlenül írást, hanem csak olvasást is jelenthet.

A fájlhoz tartozó jogok és engedélyek
A dátumokhoz hasonlóan ennek a metaadatnak is sokféle változata létezik. Ki a fájl tulajdonosa? Ki olvashatja? Ki férhet a tulajdonoson kívül még hozzá? Biztos te is fel tudsz sorolni még néhányat. Még számtalan metaadathoz tartozó információt lehetne felsorolni, például az adott fájl mappa-e? Mac OS X alatt speciális mappa is létezik, ez a Bundli (bundle), amely szép masnival átkötött csomagként képzelendõ el, sok mindent tartalmaz, de te, mint felhasználó egy elemként, fájlként használod és általában programként kezeled. Tehát léteznek olyan metaadatok is, amikkel csak bizonyos fájlok rendelkezhetnek.

A metaadat típusai

Nézzük, mit is találtunk eddig: név, tárolási hely, típus, méret, dátumok, jogok és engedélyek. Ha csoportosítani kellene õket, hogyan tennéd meg? Vannak olyanok, amelyeknek közös tulajdonságai vannak? Kiegészítésképp, amikor Get Infót kérsz egy fájlról - inkább használd az Inspectort, amit az alt++I kombinációval érhetsz el, azért hasznosabb, mert ahogy újabb elemet jelölsz ki, frissíti az információkat -, akkor megjegyzést is fûzhetsz hozzá, azonban ezt az információt a .DS_Store fájlba tárolja a Finder, nem metaadat szinten, ezért nincs a felsorolásban. A .DS_Store fájlról bõvebben az elõzõ Almalapban olvashatsz.

Kezdjük a jogokkal. Ez a legismertebb metaadat szabályozza, hogy ki, hogyan férhet hozzá az adatokhoz. A metaadat természetüket a legjobban úgy ismerheted meg, ha megváltoztatod õket. Annak ellenére, hogy a fájl elérési jogok nélkülözhetetlen információk a fájl adatáról, szabadon változtathatod õket a fájlban tárolt adatok változtatása nélkül.

Még melyik metadat típus rendelkezik ezzel a tulajdonsággal? A név és a tárolási hely például. Szabadon változtathatod a fájl helyét a fájlrendszerben, illetve akárhogy elnevezheted, a benne tárolt adat változatlan marad.

Némelyik fájlhoz tartozó idõpontnak is hasonlóan viselkedik. A létrehozási idõpont és valószínûleg utolsó elérés dátuma is, ha a fájl csak olvasható, teljesen független a hozzá kapcsolt fájl tartalmától, tekintettel arra, hogy egy fájlnak csak egy létrehozási dátuma lehet. A módosítási dátum azonban egész addig nem változhat, míg a fájl tartalma nem változott.

Tulajdonságaik alapján az ilyen metaadatokat (név, hely, jogosultságok és adott dátumok) módosítástól független metaadatoknak hívjuk, tehát anélkül változtathatóak, hogy szükségképpen a fájlban tárolt adatokat is változtatni kellene.

A hat típusból már három és felet nyugodtan belepakolhatunk ebbe a csoportba. A módosítástól független metaadat a legáltalánosabb metaadat. Majdnem mindegyik metaadat anélkül változtatható, hogy szükségképpen a tárolt adaton kellene változtatni. De nem ezek a legfontosabb típusú metaadatok.

Példaként nézzük meg a fájl méretet!
A méret is egy metaadat, de hasonlóan a tárolási helyhez, ritkán gondolják annak. Ha egy fájl által elfoglalt helyet nem tudjuk meghatározni, az gyakorlatilag használhatatlan. Az írás és olvasás során nem lehetne pontosan tudni, mikor van vége az adott fájlnak és mikor kezdõdne a másik. A fájlméretet tehát önhatalmúlag nem lehet megváltoztatni, másképp megfogalmazva olyan metaadat, ami csak akkor változik, ha a fájlban tárolt adat mennyisége nõ vagy csökken. Adatfüggõ metaadatként is nevezhetjük. A változtathatatlan metaadat egy adott bithalmazzal kapcsolódik össze, ami kívülrõl változtathatatlan. Csak egyféleképpen kaphatsz más metaadat értéket, ha módosítasz az adatokon!

Súlyos következményei vannak, ha az adatfüggõ metaadat megszorításait nem vesszük figyelembe. Ha a fájl mérete a benne tárolt adat változása nélkül mutat más értéket, azt a fájl biztos, hogy elvesztettük. A változtathatatlan metaadat inkább ártalmas, mint használhatatlan, ha nem a tárolt adat állapotát tükrözi.

A módosítási dátum is változtathatatlan metaadat. Ez a metaadat csak akkor változik, ha a tárolt adat módosításra került. Ha a fájl módosítási dátuma a fájl tartalmának a megváltozása nélkül módosul, az nem annyira katasztrofális, mint a fájlméret változása, legfeljebb napokig keresed azt az elõzõ verziós dokumentumot, amit a téves módosítási dátum alapján feltételezel, tehát ez sem a normális mûködés.

Végül itt van a fájl tartalom típusa, ami szintén megváltoztathatatlan. Érdekes hieroglifák jelenhetnek meg a képernyõdön, ha egy jpg képet szövegként próbálsz olvasni, egy szöveg fájl képként történõ használata a megfelelõ fejléc információk és adat nélkül pedig lehetetlen.

Azonban van még egy dolog, amit a megváltoztathatatlan metaadattal kapcsolatban még figyelembe kell venni, ez az adott metaadatban kifejezett pontosság. Ha bõvebb információt adunk meg egy akár változtathatatlan metaadatról, akkor az változik, a tárolt adat pedig változatlan marad.

Például letöltöttél a hálózatról egy pdf dokumentumot, majd megnyitottad a Preview programban. Tartalmaz képeket, szövegeket, de nincs benne mozgókép, se JavaScript, és élve a gyanúval lefuttatod mondjuk a pdfInspektor 2 programot, ami PDFX/3 formátum ellenõrzésére való, és kiderül, hogy ez a pdf nyomdai felhasználásra készült, majd ezt az információt elmented a fájltípus metaadatban. Tehát a tárolt metaadatot lehet pontosítani úgy, hogy magán a dokumentumban nem szükségképpen történik változtatás. Hasonlóképpen egy fájl módosítási dátumát ezredmásodperc pontossággal is el lehet látni, ha szükséges a használatához.

Ez a metaadat további általános szabályaihoz vezet. Általában a minél több információ jobb. Ha több metaadat áll rendelkezésünkre, több és jobb döntéseket hozhatunk a fájllal kapcsolatban. Ha nem ismerjük a fájlhoz kapcsolódó jogokat és engedélyeket, nehezen tudjuk megmondani, hogy akkor ki is férhet hozzá az adott információhoz. Ha pedig a létrehozási dátum csak az adott évet tartalmazza, akkor lehetetlen az adott évben elkészített dokumentumok között pontosabb sorrendet felállítani. Az információ hatalom.

Még egy fontos információ a metaadatról, ami lehet hogy nyilvánvaló, de késõbb még fontos lehet. Mint minden információt, a metaadatot is el lehet távolítani, vagy figyelmen kívül lehet hagyni, de gyakran nehéz, sõt lehetetlen újra hozzáadni, illetve elkészíteni, ha elveszett. Ha nem tudod, hogy mikor volt az adott fájl utoljára módosítva, nem tudod helyreállítani, annak ellenére sem, hogy a módosítási dátum megváltoztathatatlan a fájl adatának módosítása nélkül. Az adat megmarad, de a módosítást jelzõ információ elveszett. Gondolj csak az adatvesztéssel járó tömörítésre. Egy camera raw formátumban mentett képet elmenthetsz egy közepes minõségû jpg képbe, de ebbõl a képbõl nem tudsz egy camera raw formátumú képet kapni. Ismeretlen információt nem lehet hozzáadni. Az információ drága.

A metaadat megvalósítása

Vizsgáljuk meg a metaadat néhány tipikus megvalósítását mindazon elmélettel, ami korábban vázoltunk. Az elsõ lépés bármilyen metaadat létrehozásakor a metaadat tárolásának megvalósítása. Elõször tételezzük fel, hogy az adat, amihez a metaadat kapcsolódni fog, már valamilyen formában tárolva lett egy adott fájlrendszerben. Ezek után a metaadatnak valamilyen formában kapcsolódnia kell az adathoz, különben nem metaadat. A adat pedig a hagyományos hierarchikus könyvtárszerkezetben fájlként kerül tárolásra. Az, hogy feltételezzük a létezõ adat tárolását, számos metaadat meglétét teszi szükségessé. Ahhoz, hogy az adatot olvasható formában tároljuk, a fájl tárolási helyét, nevét és méretét valahol tárolni kell. Ez már három metaadat. Nézzük, hogyan tárolódnak ezek az adatok!

A fájlok tárolási helye általában a fájlrendszerben elosztva található, minden könyvtár tárol egy listát a benne található elemekrõl - most legalábbis ezzel a feltételezéssel élünk. Ebben az esetben a fájl tárolási helyét megadó metaadat olvasása tyúk vagy a tojás problémába ütközik. A hagyományos fájlrendszerben megvalósítva csak úgy tudod olvasni az adott fájlt, ha már ismered, hogy hol van. Tehát be kell járnod a könyvtárszerkezetet, és fel kell építened a fájl elérési útját, ami a fájlrendszer kezdetétõl (root) a fájl tárolási helyéig vezet.

Ugyanekkor a fájl nevét is ismernem kell ahhoz, hogy azt a metaadatot olvasni tudjam, illetve a fájl teljes elérési útját fel tudjam építeni. A fájl neve általában ugyanabban az adatszerkezetben tárolt, ahol az adott mappában lévõ elemek listája van. Az adott adaton belül lehet egy belsõ mutatód, amivel az aktuális adatot írni és vagy olvasni tudod, mondjuk egy szabványos Unix fájl leíró, de ez nem szükségképpen jelenti azt, hogy a fájl nevét csak ennek a mutatónak az ismeretében le tudod kérdezni. Továbbá akármi is hozta létre azt a fájl mutatót, tudnia kellett a fájl nevét és a tárolási helyét, azaz a fájl elérési útját, hogy írni és vagy olvasni tudja az adott fájlt.

Tehát a fájl neve és a tárolási helye kritikus a hagyományos fájlrendszerben, ezek ketten a fájl azonosítóját, elérési útját alkotják. Minden külön adatnak egyedi elérési úttal kell rendelkeznie, ha azonosítható módon szeretnéd lehívni és módosítani. Magyarul azt és csak azt a fájlt manipulálod, amit szeretnél. Ebben az esetben nehéz a névrõl és a tárolási helyrõl, mint metaadat részekrõl beszélni, mert nem lehet egy adott fájl nevérõl és tárolási helyérõl beszélni, csak akkor, ha már eleve ismert ez az információ. Ezek után, ha nem tudod a fájl elérési útját, akkor honnan tudod, hogy melyik fájlról van szó?

Ez az elméleti probléma a fájlok és fájlrendszerek hagyományos megvalósításának az öröksége. Ha teljesen eltávolodunk a hagyományos fájltárolási feltételezésünktõl, egy másik fájl azonosítót is választhatunk, mondjuk egy egyedi számot, és megszabadíthatjuk a fájl nevét és a tárolási helyét abból a kellemetlen helyzetbõl, hogy egy olyan metaadat, amit nem ismerhetünk csak akkor, ha már eleve ismerjük.

Ennek az egyedi azonosító használatának az elmélete általánosan elterjedt a relációs adatbázisok világában. Az adatbázis tervezéseknek egy lényeges mozzanata, hogy kívánatos egy egyedi érték használata, amellyel egy adatbázistáblában egy adott sort egyértelmûen ki lehet választani. A hagyományos fájlrendszerek különböznek ettõl az elképzeléstõl, hiszen két információt, a nevet és tárolási helyet használnak a fájl elérésének kulcsaként. Néhány fájlrendszer, mint a HFS+, lehetõséget ad bizonyos körülmények között egy egyedi fájlazonosító használatára, de a név és a tárolási hely használata általánosan és a széleskörûen használt azonosító.

A fájlméret metaadatot kétféle formában tárolják. Elõször is ismerni kell, hogy a fájlrendszerek rendelkeznek egy minimális blokkmérettel, ami a legkisebb elfoglalt tárterületet jelenti. Ez az a minimális tárterület, amit egy fájl elfoglal, ha tárolásra kerül. Ha a fájl mérete nagyobb, mint egy blokk, akkor több blokkot foglal el, amelyek között egy adott utat kell megtenni az olvasás során, hogy a teljes fájl beolvasásra kerüljön.

A fájl nagyságát gyakran a fájl kezdõ és végpontjából, és az egyiktõl a másikig tartó útvonal - ez jellemzõen az adatblokkok közötti mutatók sorozata - hosszából számolják. Ez az információ tárolódik el ideiglenesen a fájlrendszerben, hogy ne kelljen minduntalan végignyálazni a fájl adatrészeit, valahányszor kíváncsiak vagyunk a fájl méretére. Ha teljesen el akarod veszteni a fájl méretérõl szóló metaadatot, akkor el kell vesztened magát a fájl nyomon követését a fájlrendszerben.

Tehát a fájl neve, tárolási helye és a mérete nélkülözhetetlen metaadat, mert ezek nélkül a fájl nem használható. A méret adattól függõ metaadat, a név és a hely adattól független metaadat, ami azért is érdekes, mert ez a két adattól független metaadat alkotja a fájl elérési útját, ami nélkülözhetetlen a használathoz.

A fájlhoz tartozó dátumok, engedélyek és jogok a nélkülözhetõ metaadatok közé tartoznak, mert a fájl egy hagyományos hierarchikus fájlrendszerben használható formában létezhet ezen metaadatok nélkül. Mindegyik fájlrendszer tárolja fájlhoz tartozó dátumokat, legalábbis a létrehozási és a módosítási dátumokat.

Az engedélyeket és a jogokat megvalósító metaadatokat olyan hálózati, és/vagy többfelhasználós operációs rendszerek fájlrendszerei használják, mint a Mac OS X. Ezeket a dátumokkal együtt külön erre a célra fenntartott metaadat-szerkezetben tárolják a más nélkülözhetõ metaadatokkal együtt. Végezetül a fájltípus is nélkülözhetõ metaadat, tehát a névvel, tárolási hellyel és a mérettel ellentétben nem nélkülözhetetlen a fájl sikeres eltárolásához és a lekérdezéséhez. Ez adattól függõ, tehát nem változtatható meg a tartalmazott adat megváltoztatása nélkül, kivéve a pontossági meggondolást persze.

Sajnálatos módon a legtöbb magasabb szintû fájlmûvelet, mint a megnyitás, szerkesztés nehéz vagy lehetetlen, ha a fájltípus metaadat hiányzik. Gondolj csak arra, mikor egy Mac OS 8 alatt készült képet kiterjesztés nélkül küldtél el egy PC-s stúdióba, az operációs rendszer nem tudta, milyen fájl és az általában szöveges állományként végezte, de ne szaladjunk ennyire elõre.

Nézzük tehát meg a fájltípus metaadat megvalósítását a modern operációs rendszerekben és hálózatokon, kifejezetten a Mac platform sajátosságaival, avagy kezdõdjön az õrület!

A fájltípus dilemma

Ha az elõzõekben taglaltakat figyelembe vesszük, mégis hogy van a fájltípus metaadat tárolva? Ez egy adattól függõ, de technikailag nélkülözhetõ metaadat, ami azonban kritikus fontossággal bír, ha a felhasználó által a fájllal történõ mûveletekrõl van szó. Mielõtt megnéznénk, hogy hogyan is tárolható, vizsgáljuk meg, miért is annyira fontos ez a metaadat.

A fájltípus a fájlban található adatok tárolása szempontjából nélkülözhetõ metaadat, mert a az adat lehívása és eltárolása ettõl függetlenül történhet meg. Az adat az, ami valójában érdekel minket. Az operációs rendszer dönthet más elérhetõ metaadatok esetén például az adat módosításának lehetõségérõl az elérési jogok alapján, a biztonsági mentés esedékességérõl a módosítási dátumok alapján, de a fájl tartalmának a változtatásához csak magára az adatra van szükség, amit a fájl nevének és az elérési útjának a kombinációjával adhatsz meg, és a fájl nagyságával és a hozzá tartozó bejárási útvonalával, tehát a méretének az ismeretével tudod olvasni.

A fájltípus akkor jön a képbe, ha a felhasználó közvetlenül akarja azt a bizonyos fájlt módosítani. Napjaink számítástechnikai rendszerében fájlok megtekintéséhez és szerkesztéséhez programokra van szükség. A programnak csak a fájlban található adatra van szüksége, a használandó program kiválasztásakor azonban ismeri kell a fájl típusát, formátumát, tartalom típusát, vagy ahogy akarod úgy hívod annak a rakat bitnek a tulajdonságát, amik azt a bizonyos adatot felépítik. Egy képrõl van szó? Ha igen, akkor egy képszerkesztõ program lehet a logikus választás. Ha egy hangállomány, akkor egy másik program lesz a megfelelõ.

A felhasználó magát a programot is kiválaszthatja, a programból is megnyithatja az adott állományt, ebben az esetben a fájltípusnak valamilyen formában elérhetõnek - láthatónak - kell lennie, hogy tudja, melyik programot kell kiválasztania ahhoz, hogy az adott fájlt ki tudja nyitni. A grafikus felhasználói felületekben a manipulálásra szolgáló program kiválasztását az operációs rendszer is elvégezheti. A fájl duplaklikkel történõ megnyitásakor az operációs rendszer megnézi a fájl típusát és megnyitja a megfelelõ programot.

Hasznos pontosan megvizsgálni, mit is lehet fájltípusként eltárolni. Az átfogó típusok, mint a kép, vagy a hang kevésbé hasznosak, ha egy programnak kell az adott fájlban tárolt adatot beolvasni és helyesen értelmezni, itt már a "inDn" és "JPEG" típusok szükségesek. Bizonyos esetekben még több részletre van szükség. Ha egy dokumentumot mondjuk csak Indesign doksiként ismertetünk fel, nem elégséges, gondolj csak a CS és 2.0 verziókra az adott programból.

Tehát pontosan el kell döntenünk, mit is akarunk eltárolni. A dátumokkal kapcsolatban csak a pontosság lehet döntõ, napok, másodpercek, vagy ezredmásodpercek. A fájlméret ehhez hasonló, blokkok, bájtok, vagy bitek. A fájlnevek és a tárolási helyek csak a megjeleníthetõ hossz és a kódolás alapján függenek, ha a maximális egymásba ágyazott mappák száma nincs korlátozva. A jogokat és az engedélyeket az operációs rendszer biztonsági modellje határozza meg, de a fájltípus metaadatnak rengeteg lehetséges tárolási formája van. Gyakorlatilag a pontos és az átfogó információ egyidejûleg megadható, így értelmes döntés születhet, melyik program tudja olvasni és melyik tud egyáltalán valamit kezdeni az adattal.

Ha megvan a mit, lássuk a hogyant! Egy adattól függõ, de nem nélkülözhetetlen metaadatról van szó, ami különösen fontos a felhasználói fájlmûveletek szempontjából. A korábbi fájlrendszerekben, amelyek már kezelték a fájltípus metaadatot, az összes metaadat egy elõre meghatározott helyen tárolódott a fájlrendszerben. Akkoriban a méret korlátozó tényezõ volt, és szükség szerint a fájltípus metaadatot nyers formában tárolták.

Ez egyáltalán nem probléma, mert más metaadatokat is hasonlóképpen korlátozták. A fájl tulajdonosát egy rejtélyes felhasználó azonosító formájában tárolja a rendszer, de automatikusan megtörténik a fordítás, ha az 501 tulajdonos tudni szeretné, hogy õ éppen Béla.

De a fájltípus metaadatot nyers a formában tárták a felhasználó színe elé, gyakran pár karakterként, mint a "TXT" vagy "COM". Viszont ha elég jó vagy rövidítések kezelésében, kapásból tudod, hogy a "TXT" text fájlt jelent, az 501-es azonosítóval azonban már bajban lennél. Továbbá a nyers formában tárolás memóriát, processzor idõt és programozói fáradságot spórolt - csakk tárhelyet nem -, amelyek szükségesek lettek volna ahhoz, ha valamilyen más formátumból kellett volna minden egyes fájltípus lekérdezésnél kibányászni az értelmezhetõ adatot. Így a fájltípus tárolása közvetlenül, azonnal értelmezhetõ módon történt, nyers formában lett megjelenítve.

A következõ operációs rendszerek a fájltípust a fájlt azonosító harmadik összetevõként valósították meg, hozzácsapták az elérési úthoz és a névhez. Egy fájl megadásához tehát tudni kellett a típusát is. Ez azt is jelentette, hogy ugyanabban a mappában több ugyanolyan nevû elem is lehetett, ha különbözõ volt a típusa, akkor nyugodtan megvoltak egymás mellett. Ezt a helyzetet megoldva összerakták a fájltípus és a fájlnév metaadatot, mind a szerkesztés és a megjelenítés során úgy, hogy egy "." ponttal elválasztották õket. Ez nem lett volna akkor baj, de teljesen figyelmen kívül hagyták, hogy a fájltípus metaadatot külön kell tárolni a többi metaadattól. Így születtek meg a fájlnév kiterjesztések.

Viszont az ide vezetõ út egyik döntése sem tûnik oktalannak. A metaadat rövidített természetét az akkori tárolási korlátok adták, a nyers mivoltot az az emberi képesség, hogy könnyen felismerhetõek legyenek a rövidítések. A fájltípus és a fájlnév metaadat végleges kombinációja a szerkesztésben és a megjelenítésben logikusan következhet abból, hogy a nevet és a típust a könyvtár listázások során mindig egymás mellé tették.

Tekintetbe véve mindazt, amit a metaadatok besorolásáról eddig mondtunk, nézzük meg, mi is lett a végeredmény! Egy adatváltozástól függõ metaadatot összehoztak egy a fájlban tárolt adattól nem függõ metaadattal, Cupido szerepével pedig a "." karaktert bízták meg. Azonban nem ez a legjobb és a legcélszerûbb megoldás!

A kiterjesztések nem oldották meg a már létezõ megvalósítási problémákat. A fájltípus metaadatnak már volt egy erre a célra kijelölt tárolási helye a fájlrendszerben. Semmilyen korlátozás nem volt, ami erre kényszerítette volna a fájltípus tárolását.

A kiterjesztések öröksége

Azzal, hogy a fájltípus metaadatoknak eltávolították a tárolási helyet, és összeillesztették a fájlnévvel, azt jelenti, hogy a fájlban tárolt adattól függõ metaadatot változtatni lehet azzal, hogy egy a tárolt adattól függetlenül változtatható adatot módosítasz. Azaz a fájl átnevezésével más fájltípust rendelhetsz hozzá. Nem egy szerencsés dolog, de nézzük mi történt volna akkor, ha nem a fájltípust, hanem a fájlméretet tüntetné fel kiterjesztésként a rendszer.

A fájlneveket tetszõlegesen hosszan, kis és nagybetûvel használhatjuk, egy pdf mondjuk "Prospektus Vegleges.576k" vagy "Kiloves korrektura.12MB" nevekkel lennénk tele. A kettõ közötti különbség csak annyi, hogy a fájlméret nélkülözhetetlen az adat lehívásához és írásához, ha belevesszük, hogy át is írhatom anélkül, hogy a fájl változhatna, borzalom. Egy olyan metaadat lett akármikor változtatható, aminek nem lenne szabad, csak a fájlban tárolt adattól függõen változnia.

Persze igyekeztek kiküszöbölni ezt a tervezési hibát is, alapesetben az operációs rendszerekben a fájlnév kiterjesztések - hogy benne van a névben, mintha hozzá tartozna, pedig dehogy - rejtettek, átnevezés esetén is. Viszont az a döntés, ami a fájltípus metaadatokat a fájlnévbe tuszkolta, megszüntette a fájltípus tárolására szolgáló fájlrendszerbeli lehetõségeket.

De volt valaki, aki másképp gondolkodott, mégpedig kedvelt platformunk gyártója. A grafikus operációs rendszerét és az általa kitalált metaadat megvalósítást a másik oldal nem tudta átvenni, és ez okozta ennek a jól kitalált rendszernek a vesztét. De mi is volt ez tulajdonképpen?

Ha emlékszel a bemutatott alapokra, pontosan ugyanaz történt almáéknál is. Eldöntötték, milyen metaadatok azok, amiket tárolni akarnak és minden metaadat részt a fájlrendszeren belül a megfelelõ metaadat szerkezetben helyezték el. Minden felsorolt metaadatot, tárolási hely, név, méret, típus, dátumok és hozzáférési jogok, adott formában tároltak el.

Az Apple a fájltípus információt nem a fájlnévben tárolta. Ez jelentõsen növelte az akkori felhasználói élményt és a Mac fõ szépségének is nevezték. A Mac felhasználóknak nem kellett a fájltípussal foglalkozni, ha egy fájlt el akartak nevezni, az egy mappán belüli azonos névvel rendelkezõ elemeket nem engedte a rendszer. Ha kíváncsiak voltak az adott fájl típusára, akkor bõbeszédû üzenet tájékoztatott, "Adobe Photoshop 2.5 LE Document" és ez rendben is volt. De nem állt meg itt a dolog, további metaadatok kerültek a fájlok mellé, amelyek más platformokon nem találhatóak meg, még több információt adva. A legszembeötlõbb annak a metaadatnak a tárolása, ami a fájlt készítõ programot jelezte. Ezeket a program-kapcsolásnál használta fel a rendszer arra, hogy megtalálja a fájlt készítõ programot, ha ez sikertelen volt, akkor megnézte a fájltípust. Ez azt jelentette, hogy két ugyanolyan típusú fájl két különbözõ programban nyílhatott meg. A program nyitás teljesen független volt a fájl típusától és a nevétõl.

Ezt a remek felhasználói élményt tehát a fájltípus kódon (File Type) és a fájlt készítõ programkódon (Type Creator) alapuló program nyitás, és a fájlnév feletti teljes uralom biztosította. De sajnos nem csak Macintosh számítógépekbõl áll a világ, és az Internet mindent átható elterjedésével az így kialakított metaadat környezet hátrányossá vált, mert többre volt képes.

Mac az Internet korban A fájlok mindig is platformok között közlekedtek, de az Internet elterjedése az ilyen módon történõ adatátvitelt még inkább könnyebbé és elérhetõvé tette. Ez a metaadatok szempontjából kétféleképpen okoz gondot: 1. fájlok küldése másik platformra: az így küldött fájlok csak azokat a metaadat részeiket tartják meg, amiknek a másik platform fájlrendszerében tárolási helyük van. 2. fájlok fogadása másik platformról: az így fogadott fájlok csak azokkal a metaadataikkal fognak rendelkezni, amik a másik platformon már léteztek (általában kevesebb, mint a Mac platformon), a fájltípus metaadatuk pedig a fájlnévben található. A probléma megoldására elkészítettek egy adatbázist, ami a Mac típusú metaadatok és a "idegen" platformról származó fájlnévben tárolt fájltípus információ közötti kapcsolatokat tárolja. Ez volt a File Exchange vezérlõpult a Mac OS 9 rendszerben. Ha a Mac program küldött egy fájlt a másik platformra, a fájltípus metaadatot a fájltípus alapján átírhatta a kiterjesztéses formára, így a fogadó oldalon a fájltípus metaadat a platformnak megfelelõ formában tárolódhat az adott fájlrendszerben, illetve jelenhet meg az ottani felhasználónak. Egy olyan program, amely a fájlnévben tárolt típus metaadatú állományt kezelte, az adatbázis alapján beolvashatta a megfelelõ fájltípus információt, illetve az adott fájlban frissíthette is ezt a metaadatot. Ez lenne a Kánaán, mert nem a felhasználónak kell foglalkozni azzal, hogy a fájltípus metaadatot bizgeti, viszont a programoknak támogatnia kellene ezt a funkciót. Ez gyakorlatilag is lehetségessé vált, de sajnos elõbb ragasztották rá a Mac gépekre a rossz Internet rendszer nevet, pedig ez nemcsak metaadat tárolás megvalósításából eredt. A Resource Fork A Mac fejlesztésekor a készítõk a széleskörû metaadat támogatással nem elégedtek meg. Az adatok számára egy másik tárolási lehetõséget is készítettek, ez volt a Resource Fork. A hagyományos adattárolási rendszerekkel ellentétben, amelyek egyszerû bitfolyamot használnak, ez a tárolási lehetõség az operációs rendszer által kialakított szerkezetû. Mindemellett az adatok tárolására hagyományos bitfolyam is megmaradt. Hogy a két különbözõ adattárolási rész között különbséget tudjanak tenni, amelyeket az Apple Forkoknak (adatrész) neveztek el, a hagyományos bitfolyam részt Data Forknak (adat adatrész), a szerkezettel ellátott tárolási részt pedig Resource Forknak (forrás adatrész) hívják.

Általában a Resource Fork egyáltalán nem tartalmazott metaadatot. Az eddig tárgyalt metaadatokból egyet sem. A programok esetében a Resource Fork a program által olvasható fájltípusok jegyzékét, felhasználói felület elemeket, képeket, hangokat tartalmazott, ezért a programokhoz tartozó metaadatnak egy típusaként lehet tekinteni. De ha egy fájlnak volt Resource Forkja, az túlnyomórészt adat volt.

A Resource Forkot a hatékonyság növeléseként és a program mûködéséhez szükséges elemek és a programkód közötti jobb megkülönböztethetõség miatt hozták létre. A program átültethetõ nyelvi elemeit, képeket, a felhasználói felület elemeit, és más a mûködéshez szükséges részeket tárolhattak a szerkezettel rendelkezõ forrás adatrészben, ahol egyenként lehetett olvashatóak és módosíthatóak voltak anélkül, hogy az egész Resource Forkot be kellett volna tölteni a memóriába.

Hogy mi köze van a Resource Forknak a kis elméleti fájlodhoz? Csak annyi, hogy bizonyos esetekben adat fájlok is tartalmazhatnak Resource Forkot, amely másolás esetén, ha nem tárolható a másik platform fájlrendszerének metaadat-szerkezeteiben, akkor elvész és a fájl használhatatlaná válik.

Azt hihetnék, hogy a fájltípus és a fájlt létrehozó program-metaadatot a forrás adatrészben tárolták, pedig nem. Ez a két igen jellegzetes metaadat a fájlrendszer metaadatok tárolására szolgáló adatszerkezeteiben van elrejtve, a többi metaadattal együtt. A másik téves gondolat azoké, akik e két metaadatot okoljak a Mac fájlok hordozhatatlanságáért. Mivel a többi platform adatai mind egy Forkot támogató fájlrendszereken tárolódtak, a két Forkos (Data és Resource) Mac fájlok másolása esetén a Resource Forkok elvesznek, mert nincs tárolási helyük a másik fájlrendszerben, illetve az adatátviteli közegben. A Forkokat és a metaadatokat egyetlen bitfolyammá kell összeolvasztani ahhoz, hogy használhatóak legyenek. Az egyik ilyen kódolási módszer a "MacBinary", ami mind a metaadatokat és az Resource forkokat is elhelyezi a fájlban. Ha a Resource Forkkal is rendelkezõ Mac fájl nincs bekódolva, akkor hálózaton keresztül adatvesztés nélkül nem lehet elküldeni. Mivel az Internet az egyszerû bitfolyamra épül, minden e közegen keresztül küldött fájlt be kell kódolni, hogy a másik oldalra megérkezve megtartsa a tulajdonságait, még azonos, tehát Mac platform esetén is.

A Resource Fork elsõdlegesen adatot és nem metaadatot tartalmaz. Ezt az információt nem lehet veszteség nélkül elhagyni, emlékszel, ilyen a fájl létrehozási dátuma például. Ez nélkülözhetetlen adat, ami nélkül a fájl használhatatlan. Aki azt mondja, hogy "A Mac gépek nem tudnak az interneten keresztül fájlokat küldeni, mert File Type és Type Creator metaadatokat tartalmaznak a fájlnév kiterjesztések helyett" - az téved. Legfeljebb a fogadó oldalon kell barchobázni, hogy milyen fájl is jött az éterbõl tulajdonképpen. A Mac gépek csak olyan fájlokat nem tudnak az interneten megosztani, amiknek Resource Forkjuk van, es nem történt meg például a "MacBinary" bekódolásuk még az átvitel elõtt.

És lõn a Mac OS X

Eleve úgy tervezték, hogy a Mac együttmûködési problémáit megoldja. A Resource Forkok kezelése bizonyult a legnagyobb problémának, mert inkább terjedelmes és nélkülözhetetlen adatmennyiséget, mintsem tetszõleges metaadatokat tartalmaznak. Az alkalmazott megoldás figyelembe vette, hogy a Resource Forkok inkább a programokban, mintsem a dokumentumokban találhatóak.

Néhány Mac dokumenum tartalmazhat Resource Forkokat, mint például az a szövegszerkesztõ programdokumentum, ami a sima szöveget a Data Forkban tárolja, a hozzá tartozó formázási és stílusinformációt pedig a Resource Forkban - ami azért hasznos, mert a dokumentumot bármely szövegszerkesztõben meg lehet nyitni, igaz formázások nélkül. De hála az internetnek, és a keresztplatformos fájlcseréléseknek, a Resource Forkokat tartalmazó dokumentum formátumok kezdenek a múlté lenni. A legtöbb Mac program lapos (flat) fájlokat készít, amiket kódolások nélkül, szabadon lehet hálózaton, akár más fájlrendszert használó platformokra is küldeni.

Szerencsére a NeXT fejlesztõi már kitaláltak egy remek módszert hasonló problémákra, mint ami a Resource Fork okozott(?), ez pedig a kötegelt fájlok, azaz a csomagok (bundles) alkalmazása. Ezekben a csomagokban ugyanúgy adatok találhatóak, mint a Resource Forkokban, a belsõ szerkezet pedig szintén adat formájában tárolt a Bundlin belül. A hagyományos fájlrendszerben az adott programmal kapcsolatos minden adat és Resource megtalálható bennük. Ez egy könyvtárszerkezetben valósul meg, ami egy elemként látszódik a felhasználó felé. Az új, 1.2-es verziójú Safari böngészõ is Bundli formájában tárolja a teljesen le nem töltött fájlokat, próbálj meg átnevezni egy akármilyen fájlt .download kiterjesztésûre, és máris egy le nem töltött fájl ikonját kapod, ami csak azért nem jelez ki töltöttséget, mert nincs benne egy xml fájl, ami ezt jelezné. Bármely Bundli tartalmát a jobbklikk "Show Package Contents" paranccsal tudod kinyitni, az info.plist fájlban pedig a .download esetében a letöltés linkjét is megtalálod.

Természetesen a klasszikus Mac OS Resource-ainak a támogatását nem lehet teljes egészében elhagyni. De mivel a program Bundlikban már több fájlt lehet egyként megjeleníteni, a Resource Forkok helyett Resource Fájlok használatát ajánlja az Apple. A Resource Fájlok egyszerûen sima fájlok, ahol az a szerkezettel rendelkezõ adat, ami egykor a Resource Forkban volt, már a Data Forkban található egyszerû bitfolyamként. Ezen kívül a Resource Fájlokat szabadon lehet platformok, fájlrendszerek és hálózatok között küldeni bárminemû adatvesztés nélkül. Igen, más fájlrendszerek között is, pl. UFS. Ezt az együttmûködést a Finder azon képessége teszi lehetõvé, hogy Flat fájlrendszereken - ez azt jelenti, hogy csak egyforkos, sima bitfolyam tárolására képes a fájlrendszer - is képes Resource Forkok tárolására rejtett fájlok használatával. Ez régi Mac OS program esetén biztosítja a a NeXT-tõl örökölt UFS fájlrendszeren a használatot. A Finder bármilyen fájlt képes UFS kötetrõl, illetve kötetre másolni bármilyen adat és metaadat veszteség nélkül.

A Bundlik és a Resource Forkok használatával olyan programokat lehet készíteni, amelyek használhatnak klasszikus Resource-okat, mégis hordozhatóak maradnak. A másik oldalról nézve egy Mac OS X programban Resource Fork használata nélkül lehet klasszikus Mac OS Resource-okat elhelyezni.

Így már a Resource forkok nem jelentenek problémát, a klasszikus Resource-okat pedig Resource fájlokként tárolva a Mac együttmûködési dilemmája megoldódni látszik. Pusztán a fájltípus és a létrehozó típus kicserélésének a problémáját kellene megoldani, és minden szuper lenne.

A NeXT által alkotott program Bundlikkal, az Apple általi Resource fájlokkal és a felhasználó által beállítható kiterjesztést File Type és Type Creator kódba cserélõ táblával, amit az Apple a Mac OS 9 számára készített, elsõ osztályú hálózati rendszerként képes lenne más, kevésbé széleskörû metaadat támogatással rendelkezõ fájlrendszerekkel az adatcserére, és a Macintosh gépektõl elvárt felhasználói élmény se csorbulna.

Sajnos nem ez a megoldás az, amit az Apple alkalmazott a Mac OS X-ben. A Resource Forkokkal ellentétben a metaadatokat nem a fent említett módon kezeli. Ez most hiba vagy tulajdonság? Ez attól függ, hogy hogyan tárolja a fájltípus-metaadatot. Az alapértelmezett fájlrendszer a HFS+, ezért elvárható lenne a Mac OS 9-ben megszokott megvalósítás, minden metaadat a HFS+ formátumban beépített metaadat szerkezetekben történõ tárolása. Valójában minden metaadatra igaz ez a Mac OS X-ben, kivéve a fájltípus metaadatra.

A fájltípus metaadat a Mac OS X-ben
A hivatalos fájltípus tárolás szerint a típust kétféleképpen kell megadni. File Type kóddal, amit a fájl metaadataként kell eltárolni és a fájlt helyesen jellemzõ több fájlnév kiterjesztéssel, mint a .html vagy a .htm. Tehát a Mac örökséget szem elõtt tartva a névtõl független metaadatként is el kell tárolni a fájltípust, illetve a népszerûbb platform mintegy "ajándékaként" a fájlról nélkülözhetetlen, ámde a benne tárolt adattól függetlenül változtatható fájlnévben is fel kell tüntetni.

Az egészben az a gond, hogy egy megadási mód is elegendõ lenne a fájltípus felismertetéséhez, tehát az egyik megvalósítás felesleges, az Apple szerint kötelezõ a kiterjesztések használata már a fájl létrehozásakor. Azonban elegendõ lenne csak a más platformokra küldéseknél hozzábiggyeszteni a kiterjesztést, így a kompatibilitás is megmaradna. De hozzá kell szokni, hogy ha egy fájlt elnevezünk, akkor a kiterjesztésre is figyelni kell, ha nemcsak Mac platformon lesz az adott fájl használva.

A felhasználó késõbb módosíthatja a kiterjesztést és viselheti a következményeket. A kiterjesztések elrejtésével meg elõfordulhat, hogy egymásután több kiterjesztést megad, amibõl csak az utolsónak van hatása.

Az elmélet próbaköve a gyakorlat, kapd elõ a Script Editort, az elkészített szkript, mivel futtatható, resource forkot is tartalmaz, szükség van még az UFS fájlrendszerre, ha nincs UFS partíciód, de van pl. USB-ceruzád, az adatok biztonságba helyezése után formázd le UFS-re, az adott ablakra jellemzõ nézet beállításoknál kapcsold ki a Show Item Preview (Mutasd az elem képét) pontot és izzítsd be a Terminált! Elõször is, a kiterjesztések megjelenítését állítsd be (Aktív Finder, + , kombináció, Advanced, Show all file extensions jelõlõnégyzet)! A Script Editorban készítsd el a következõ szkriptet, ami a www.almalap.hu szöveget jeleníti meg, majd mentsd el sima Applicationként, majd Application Bundleként.





így két szkriptet kapsz, ami látszólag megegyezik.



Futtathatod õket, ugyanúgy mûködnek, a fájlrendszerben történõ tárolásuk történt másképpen. Az desktopon található harmadik elem egy kép, aminek Photoshopban elölnézeti képet adtam, amit a fájl Resource Forkjában tárol a Mac OS X. Most HFS+ fájlrendszerben csücsülnek, nézd meg, mit mond az ls -la parancs.



Minden szkript végén szerepel egy láthatatlan '.app' kiterjesztés, ami csak akkor bukkan elõ a Finderben, ha megpróbálsz egy másik kiterjesztést adni, de a Bundliként elmentett szkript valójában egy mappa. A G opcióval rekurzívan is ki tudod listázni az elemek tartalmát, tehát
ls -laG ~/Desktop/
ha az íróasztalodra mentetted le a dolgokat. Nagyon sokféle fájlt listáz ki ugye? Ezek mind-mind Resource Fájlok, a Resource Forkot helyettesítik. Nekem a Boken ceruzám lett UFS formátumú, át is másolom gyorsan, de most a Finderen keresztül, mert a unix parancsok nem értelmezik a Resource Forkokat, a Finder viszont igen. Nézzük, hogyan vannak tárolva az UFS alatt:



Mindegyik fájl kapott egy "._" elõtaggal rendelkezõ társat, ami a fájlban lévõ Resource Forkot jelképezi, tehát inkább adat, mint metaadat, hiszen önállóan is rendelkezhet metaadatokkal. Az összes ilyen fájlnak a létrehozási dátuma a fájlmásolás dátumával egyezik meg, nem a Data Fork létrehozási idõpontjával. A Bundlinak a resource Forkja nagyságrendekkel kissebb, mint a csak Applicationként elmentett szkripté. Most külön tudod másolni a két szkript és a kép Data és Resource Forkját, most már használhatod a cp parancsot, hiszen mindkettõ sima bitfolyam. Ha eddig nem volt bekapcsolva a láthatatlan fájlok láthatósága, akkor kapcsold be, bõvebb infót errõl az elõzõ Almalapban találhatsz.

Külön másold vissza az adott fájlokhoz tartozó Resource Forkokat a
# cp /Volumes/Boken/._* ~/Desktop/
# cp -r /Volumes/Boken/almalap* /Volumes/Boken/apple.jpg ~/Desktop/
parancsokkal, a -r opció a Bundli miatt kell, mert az tulajdonképpen egy mappa. A Bundliként másolt szkriptnek helyes ikonja van, fut is, nem sérült a másolás közben, azaz nélkülözhetõ volt a Resource Forkjának a tartalma, hála a Resource Fájloknak. A képet ki lehet nyitni, de kis ikon képe a Resource Forkjában van, ami külön fájlként található mellette. Az Applicationként elmentett szkript nem több egy használhatatlan adathalmaznál. De nincs semmi veszve. A /System/Library/CoreServices/ mappában található egy FixupResourceForks parancs, ami az egymáshoz tartozó Forkok összeolvasztására való.
/System/Library/CoreServices/FixupResourceForks ~/Desktop//private/var/root/Desktop/._almalap.app

/private/var/root/Desktop/._almalap_Bundli.app
/private/var/root/Desktop/._apple.jpg
/private/var/root/Desktop/almalap_Bundli.app/Contents/Reso urces/Scripts/._main.scpt

A futás során ki is listázza, hogy melyek azok a Resource Fork nevek, amelyeket egybeolvasztott. Az utolsó sor szerint a Bundliban lévõ szkriptet tároló fájl is tartalmazott Resource Forkot. Az almalap szkript is futtatható, a képnek is látszik a tartalma. Tehát nem kell megijedni, ha "._" elõtagú fájlnevekkel találkozol.

Más platformokkal történõ levelezések során elõfordulhat, hogy csatolt fájlt kell küldened. A Send Windows Friendly Attachments bekapcsolása figyelmen kívül hagyja a csatolt fájl Resource Forkját, így anélkül kerül küldésre. Ha Mac gépek között van adatcsere, nem szükséges bekapcsolni. Hiszen a fogadóoldalon is tárolhatóak a Resource Forkok.

Az átnevezések hatásai

Az ikonnal összeolvasztott képen nézzük meg, milyen hatásai is lehetnek, ha anélkül változtatod meg a fájltípust, hogy a fájlban tárolt adat is változott volna. Az adat tehát egy kép, aminek a Resource Forkjában elölnézeti képe van. Nevezd át a ".jpg" kiterjesztést ".txt"-re. Az ikonkép marad, de duplaklikknél a TextEdit nyílik meg, a jpg mivoltra csak a fejlécben található pár értelmes karakter, illetve a kicsivel lejjebb található beágyazott xml fájl szöveges információja utalhat. Ha ".rtf"-re nevezed át, az ikonkép még mindig marad, de már a TextEdit nem nyitja ki, nem találja a megfelelõ rtf információkat.



A Preview alapesetben nem akarja kinyitni, ha az alt+ kombinációval ejted rá az ikonjára, belesápad, de nem nyitja ki. Most le is törölheted a fájl Resource Forkját, akár az UFS fájlrendszerre történõ másolással és a Data Forknak a visszamásolásával, készíthetsz egy cp másolatot, vagy ablakbarát módon emailben is elküldheted magadnak, az eredmény ugyanaz.

# cp ~/Desktop/apple.rtf ~/Desktop/apple.rtf
cp: /var/root/Desktop/apple.rtf and /var/root/Desktop/apple.rtf are identical (not copied).
# cp ~/Desktop/apple.rtf ~/Desktop/apple_.rtf

Láthatod, hogy miért fontosak a metaadatok. Ugyanolyan névvel akartam a másolatot készíteni, de mivel ugyanaz volt mindkettõ azonosítója, nem történt meg a másolás, adatvesztés. Az "_" azonban helyes, az eredmény:



A fájlban tárolt adathoz nem nyúltam, a fájltípus metaadat módosításának mégis egy formázást tartalmazó szöveges állomány neve és ikonja az eredmény. Az ".app" e kedvencem, ha az adott fájl rendelkezik Resource Forkkal, akkor Classic Application típust, ha nem, akkor sima Application típust társít a jpg képnek, a ".app" kiterjesztés rejtve marad!



A parancssort most sem felejtheted el, mert a ".app" kiterjesztést nem engedi levenni. A fejlesztõeszközök között (/Developer/Tools/) lehet azokat a másoló, illetve áthelyezõ parancsokat megtalálni, amik a Forkokat és minden metaadatot átmásolnak a bitfolyammal együtt, ezek az MvMac és a CpMac.

# /Developer/Tools/MvMac ~/Desktop/apple.app ~/Desktop/apple.jpg
# /Developer/Tools/MvMac ~/Desktop/apple_.app ~/Desktop/apple_.jpg

A képeink újjászülettek, többé nem skizofrének. Tehát a kiterjesztések fontosak. Egy baj van még, az egyiknek hiányzik az ikonja. Igen, az elveszett a cp-vel történõ másolás során, de mivel a tárolt adat ez idáig nem módosult, az egyikbõl ki lehet szedni a Resource Forkot és be lehet olvasztani a másikba. Ehhez szintén a fejlesztõeszközök között lévõ SplitForks parancsot is használhatod.

# /Developer/Tools/SplitForks -v ~/Desktop/apple.jpg
Splitting /private/var/root/Desktop/apple.jpg…
splitting apple.jpg...

Így kapsz egy ._apple.jpg Resource Forkot. Ezt át kell nevezni a másik névre, ezt a Finderbõl is megteheted.



Majd olvaszd össze a megfelelõ részeket: # /System/Library/CoreServices/FixupResourceForks ~/Desktop/

Mindvégig metaadatokat változtattál, a fájlban tárolt adat nem változott, mégis mennyi galiba történt csak a metaadatok miatt. Ha egy nem Bundli programon próbálod végig a dolgokat, ugyanezt tapasztalod. Csak a Resource Forkoknál kell jobban vigyázni, hiszen míg a képnél nélkülözhetõ, a programnál nélkülözhetetlen adatokat tartalmaz. Szerintem egyszer majd a jpg kép is Bundli lesz, a File Type és a Creator Type metaadat tárolási lehetõsége is megszûnik, történelem lesz. Apropó, mi történik, ha kitörlöd a képnél a kiterjesztést?

Mátyás Ferenc Farkas