Vacek és az öreg (2)

Vacek a buszmegállóban ült. Nézte a hömölygő autókat. Az autókban pedig a droid-folyamot, amint éppen ügyes-bajos dolgaikat szaladtak intézni. Más járt a fejében, teljesen más. Az önmagába visszamutató informatikai vektor (ÖVIV).

Amikor belépett az Öreghez, csend volt. Nem szólt semmi sem, csak a káposztástészta meghalt sercegése volt a levegőben. Kissé tétován, de direkt módon, a problémát egyetlen gondolatba összefoglalva közelítette meg a kérdést:

Hogyan tudom kikapcsolni azt, hogy a szambás szervereken ne szemetelejen tele mindent a Mac a thumbnailjeivel? Mindenki rajtam röhög. Megőrülök és ez őrjítő.

Az öreg meggyújtott egy gyertyát az asztalon, aztán töltött magának egy pohár málnaszörpöt.

Ahhoz, hogy erre a kérdésre megtaláld a választ, meg kell ismerned részleteiben a dolgokat. Megoldás, amint látni fogod nem létezik, helyette ajánlások vannak.

Ha olyan fájlrendszerrel (pl SAMBA megosztás vagy egy FAT-ra formázott partíció) szembesül Mac OS X, ami nem képes tárolni extended attribútumokat, akkor kénytelen azokat egy külön ._fájlnév rejtett fájlba elmenteni. Ilyen például a FinderInfo és a Resource Fork.

Vacek megértette mindezt, így tovább fülelt.

FinderInfo beállítás például, hogy milyen színű a címke, rejtve van-e a kiterjesztés, vagy hogy teljesen rejtett-e az egész fájl a Finder számára. Ennek a része a típus- és létrehozó kód is. A típuskód lehetővé teszi, hogy egy adott típusú fájlról bármilyen névre nevezve tudja a rendszer, hogy az adott esetben milyen formátumú állomány. Például egy PSD, mert előzőleg a Photoshop beleírta a FinderInfóba a típuskódot is.

A Resource Fork pedig lehetővé teszi többek közt, hogy formátumtól függetlenül tetszőleges ikonja lehessen egy objektumnak. Tiger aztán kiterjesztette ezt egy bármilyen program által elérhető extended attribútumok elvre, ahol a FinderInfón és a Resource Forkon kívül még tetszőleges, saját magad által definiált nevű és tartalmú plusz adatot hozzáfűzhetsz a fájlhoz.

Azóta például a legtöbb plain text szövegszerkesztő, mint a TextEdit vagy Xcode, hozzáfűzi elmentéskor a fájlhoz egy com.apple.TextEncoding nevű kiterjesztett attribútumként (xattr), hogy az a fájl milyen enkódolású. Következő megnyitáskor így már nem kell találgatni, hogy az éppen Windows-1250, KOI8-R vagy UTF-8 enkódolású-e.

._ “szellemfájl” tehát a legacy fájlrendszereken akkor jön létre, ha van a fájlnak extended attribútuma.

A webböngésző Safari a Leopardtól kezdve hasonló módon minden letöltéskor beírja egy com.apple.metadata:kMDItemWhereFroms nevű xattr-ba, hogy milyen címről töltöttük le az adott objektumot. Egy könyvtárlistában az xattrok meglétét Leopard óta egy @ jelzi:

$ ls -l ~/Downloads/
total 62208
-rw-r--r--@ 1 kt kt 31846987 Nov 7 17:51 vlc-0.9.6.dmg

Ott a @, mert van extended attribute, hiszen Safarival töltöttük le:

$ xattr vlc-0.9.6.dmg
com.apple.metadata:kMDItemWhereFroms
com.apple.quarantine

Ha tegyük fel, átszíneznénk kékre a címkét Finderben ezen az állományon, mindjárt kapna egy com.apple.FinderInfót, ha egy egyedi ikont aggatnánk rá, mint karácsonykor, akkor pedig egy com.apple.ResourceForkot is.

Tehát ha azt akarod, hogy ezt egy FAT USB flash drive-ra, vagy egy Windows fájlmegosztásra másolva ne jöjjön létre a legacy fájl-csomag, akkor azt kell elérned, hogy a fenti egyik feature-t se használd.

Néhány programban van egyébként erre kapcsoló, a GraphicConverterben állítható, hogy beállítson-e FinderInfo típuskódot a létrehozott fájlnak, adjon-e neki egyedi ikont. Sokszor viszont kikapcsolhatatlan, hiszen zöldség ilyet megkérdezni egy szerencsétlen felhasználótól, hogy akar-e extended attribútumokat a fájljára. Az egyedi ikonra például még van kapcsoló a Photoshopban, de a típuskódos FinderInfót már mindenképp beírja magától, öntörvényűen.

Mindebből az következik, hogy sok esetben az utólagos törlésük az egyedüli opció, ha nem kívánod őket. A színezést vagy az egyedi ikont törölheted Finderből, de egy típuskódtól vagy bármi egyedi xattr-ot már nem tudsz onnan egyszerűen törölni.

Leopard óta az operációs rendszerhez mellékelt xattr Python scriptet lehet ilyesmire használni:

xattr -d com.apple.FinderInfo *.psd
xattr -d com.apple.ResourceFork *.psd

Nekem annak idején Tigerben is szükségem volt xattrok manipulálására, úgyhogy írtam magamnak egy fxattr toolt, annak volt külön opciója az összes xattr törlésére.

Vacek átgondolta az egészet, morzsolgatta az információkat és mindent értett is.

Mégis, mit tehetünk az ellen, hogy ne rajtunk, Mac-eseken röhögjenek a rendszergazdák és más felhasználók, akik bekapcsolt rejtett állománnyal Total Commandereznek 2002 óta, amikor átnevezték Windows Commanderről?

Az öreg elmosolyodott.

Adhatsz a rendszergazdáidnak egyszeri, negyedórás pluszmunkát, hogy utána mindenki boldog lehessen. Ez viszont nem fog tökéletes megoldást hozni, de hallgass csak tovább.

A szakember ugyanis belőhet a Samba mellé egy Netatalk AFP fájlszervert is ugyanazokra a megosztásokra: http://netatalk.sourceforge.net/

Ezzel a Mac OS X kliensek úgy fogják gondolni, hogy az natívan képes a FinderInfo és a Resource Fork eltárolására, onnantól többet nem hoznak létre ._ fájlokat. Netatalk a háttérben a Linuxon ezeket egy meghatározott módon tárolja el, például egy .AppleDouble nevű almappába.

Azért, hogy a Windows kliensek semmi esetre se láthassák ezeket, utána ki kell egészíteni a Samba konfigurációját ezzel az egy sornyi bejegyzéssel:

veto files = /.AppleDB/.AppleDesktop/Network Trash Folder/.TemporaryItems/Temporary Items/.DS_Store/.AppleDouble/

Így még ha az amúgy izzó vassal pusztítandó rejtett fájlok megjelenítését is bekapcsolták Windowsukban a cukordinnyék, akkor se fogják tudni látni ezeket. Az AFP-vel kapcsolódó Maces klienseknek viszont megmaradnak az egyedi ikonjaik, színezett címkéi.

Vacek ezen a ponton látta meg, hogy mit lehet tenni. Melegség áradt szét benne, igaz, ánusz tájon. Az öreg viszont folytatta:

Ez egy elég radikális gondolat. Azt mondani a saját felhasználóidnak, hogy bizonyos fájlrendszerekre, megosztásokra másolva ugranak bizonyos adatok, tessék csak ezt folyton észben tartani, a grafikus és kiadványszerkesztős felhasználó legyen tudatában, hogy mikor mire másol. Főleg, ha van alternatívád, az Apple által választott jelenlegi helyzet, ahol a saját Mac felhasználóid számára minden “csak működik”. Ennek oldalán más operációs rendszerek használóit meg legfeljebb idegesíti néhány, számukra értelmezhetetlen plusz fájl, amik amúgy is rejtettnek kéne, hogy legyenek számukra. (Felteszem a kérdést zárójelben: mi a paradoxona a rejtett állományok megmutatásra beállításának?)

Megértem, hogy amíg csak a címke színéről van szó, addig könnyű azt mondani, hogy ugyan kit érdekel a hiányuk?

De vegyük például a még ma is meglepően sokak által használt klasszikus Mac formátumú fontokat. A font tartalom teljes egészében a Resource Forkban van. Kiterjesztésük ezeknek a fontoknak egyáltalán nincs, soha nem is volt rájuk kitalálva egy, helyette a Finder Infóban megjelölt típuskód jelzi, hogy micsodák.

Az elképzelt Windows-barátabb rendszerünkben egy ilyen Mac formátumú fontot képzeletbeli felhasználónk rámásol egy frissen vett, gyárilag FAT-ra előformázott USB tárolójára, és kap egy nulla hosszú, jelöletlen típusú fájlt, amiből senki vissza nem állítja az eredeti Mac fontot, mert a Resource Forkot benne az adattal nagyvonalúan kidobta a rendszer másoláskor “ugyan kinek kell az” felkiáltással. A következmények beláthatatlanok.

Látom, hogy a megoldás nem olyan egyszerű és tanítással, a történeti háttér megismerésével, a rendszerek közötti különbségek felfedezésével tudunk előrébb jutni. Elvégre mégis kettő rendszer összekapcsolásáról van szó valahol. Egyébként mi az a .ds_store?

Desktop Services Store. Azt a célt szolgálja, mint a HKCU\Software\Classes\Local Settings\Software\Microsoft\Windows\Shell\BagMRU Windowson. Leopard óta automatikusan rejtett állományként jön létre Windowson egyébként.

Vacek megértette, hogy az igazsághoz vezető út valójában egy megálló nélküli utazás, mely során mindig tágítani kell az ismereteket, amik így alkotnak stabil lelki környezetet.

32 hozzászólás

Adi

Edhellon barátom mondta jól: az OS X is szar, csak máshogy. :))

Ákos

Felcsillant a szemem, de a végére elszontyolodtam.
Valóban elképesztően irritáló ugyanis a tudat, hogy ha szeretnék zenei állományokat másolni a pendrive-omra hogy az autóban hallgathassam őket (a lemezre írást szóba sem merem hozni), át kell néznem vindózon is hogy leirtsam az említett ._fájlnév rejtett fájlokat; különben folyamatos szopásnak leszek kitéve miközben a fejegységem kétségbeesetten próbál kezdeni valamit _ezekkel_. Addig ugyanis nem tud rám figyelni, hiába mondanám hogy lépjünk tovább (egy 15 számos mappában ugye a 16. számhoz), másodpercekre lefagy.

Bíztam Benned József, gondolom az mp3-akat az iTunes címkézi fel, kérlek mondd hogy valahogy ott is ki lehet kapcsolni…

GK

Slash and Burn! Aki mégis megoldást keres a problémára, azoknak ajánlom a BlueHarvest nevű kis programot, ami lelkiismeretesen LETÖRLI az oly ciki és többségében totál felesleges rejtett fájlokat a beállított eszköztípusokról.

IIsti

Bezzeg amikor be tudod állítani minden egyes fájlhoz külön is akár, hogy melyik alkalmazás nyissa meg, akkor nem gondolod azt, hogy gázos ez a fícsör.

root33

valaki elmondaná 2 mondatban, hogy ez miről szól. Nincs kedvem végigolvasni…

iOros

# defaults write com.apple.desktopservices DSDontWriteNetworkStores true

leopard alapból nem ír ds_store fájlt pendrivra

gaba

._ “szellemfájl” tehát a legacy fájlrendszereken akkor jön létre, ha van a fájlnak extended attribútuma.

Ha a fenti állítás igaz, akkor hogy lehet az, hogy minden esetben keletkeznek ezek a gusztustalan fájlok? Minden fájlnak van eleve extended attribútuma? Ha igen, mi az?

rog

mondjuk ezekez a dolgokat ntfs data stream-be is tehetné. az milyen elegáns lenne már. 🙂

ablak

miért nem lokálisan külön helyen tárolja ezeket a kieg. infókat?

mcbuddha

“hogy egy adott típusú fájlról bármilyen névre nevezve tudja a rendszer, hogy az adott esetben milyen formátumú állomány”
Mire valo a “file” parancs?

Casper

off:

Józsi ajánlom figyelmedbe a ma megjelent Exit étteremkritikáját.

Zila

@ablak: azért nem helyben tárolja, mert ha a file-t átviszed pl. másik macre, akkor onnan elvesznek az infók. Így ha én pirosnak jelölök egy file-t, átviszem pendriveon cimbihez, ő is pirosnak fogja látni…

@rog: fat filerendszeren ntfs data stream? ugyanez Samba sharen?

sailman

Nem értem a problémát. Ezek rejtett fájlok, és a rejtett fájlokat egyik oprendszer sem mutatja alapból. Minek bekapcsolni, hogy látszódjanak, mikor pont azért rejtettek hogy ne látszódjanak?

Az Időmilliomos Apuka

Ez a cikk szépirodalom, érettségi tétel lehetne az elemzése. Mélyen együtt érzünk a szereplőkkel, velük együtt utazunk és figyeljük a kibontakozó ÖVIV drámát. Melegség áradt szét bennem az olvasása közben, szerencsére nem ánusz tájon.

Az én USB memóriámra Spotlight könyvtárat is ír az OS-X, esetleg az öreget arról is megkérdezhetné Vacek.

A szellemfájlok engem nem zavarnak, attól annál inkább falba verem a fejemet, hogy nem tudok USB memóriáról Mac-el normálisan fájlt törölni. A törölt fálj ugyanis a szemétkosárba kerül, így nem szabadul fel a helye. Az egész rendszer szemetesét üríteni kell a felszabadításához.

rog

zila: fat-on talán nem is.. de mondjuk hadd gondolkozzam egy kicsit.. megvan! egy ntfs fájlrendszeren, na azon használhatná azt ntfs stream-et ilyesmire. nem jó ötlet? aszittem.. 🙁
akkor inkább mégse. csak úgy felvetettem.

dmx

A Windows NT-k AFP fileszervere ntfs datastream-be tette a resource forkokat. Újabb Windowsokon mi az Extremez-IP-t használjuk ami jó, gyors, spotlight kompatibilis, ntfs datastream-ben tartja a resource forkokat, viszont drága.

zozo2001hu

Lehet szeretni és utálni a plastik médiát, de azt hiszem ez a post megérne egy gyémánt fokozatú közönségdíjat!

Gratulálok remek szösszenet volt!

misran

Véleményem szerint a határt ott kéne meghúzni, hogy az adott filerendszer szabályaihoz és lehetőségeihez igazodunk, nem “piszkítunk” bele, még ha erre van is technikai áthidaló lehetőség.

Egyébiránt, ha adott file-t több MAC-es is lát-elér és beállít címkéket, extra attribútumokat, stb., akkor mindenki létrehoz a file mellé egy saját szellemfile-t? Ha egy sambával kirakott file-t napi 100 MAC-es megnéz, akkor 100 szellemfile generálodik?
Köpjetek le, de ez akkor digitális kutya(pisa) az oszlopokon.

doors

Nekem úgy rémlik, hogy nem csak ntfs-en van lehetöség a fájlhoz láthatatlan stream kapcsolására

Zila

@misran: egy rejtett feile létrehozása nem a filerendszer teleszemetelése, hanem rendeltetésszerű használat. Nem jön létre 100 szellemfile ha 100 mac-be dugod az usb kulcsot, mert az a filehoz tartozik és nem a géphez. 100 file 100 mac 100 szellem-file (feltéve hogy mind a 100 tartalmaz extra attribútumokat). Példa: alma.psd ._alma.psd ha mind a 100 macen hozáírsz az alma.psd-hez valami extrát akkor mind a 100 mac ugyanabba a ._alma.psd fileba ír.

Az ntfs data streams tök jó, de csak ntfs filerendszeren, így ha egy olyan file-t írsz ki fat-re amihez tartozik ntfs ads akkor mi történik? Szerintem elvesznek az ads-ben tárolt extráid…

Amúgy érdekes ez a .DS_Store utálat, a desktop.ini file vagy a Thumbs.db miért nem zavar senkit? Ezek is hasonló célokat szolgálnak, rejtettek is alapból, mégis mindenki eltűri őket, mert az kell… Ráadásul tárolhatná a Windows ezeket ads-ben mégsem teszi pont azért mert az ads csak ntfs filerendszeren van, ami meg nincsen mindenütt (pl. cdrom-on nem is lehet, ha az usb kulcsodat mindenüt használni akarod, akkor arra fat filerendszert teszel. És bizony arra a windows is tehet mindenféle rejtett könyvtárakat. De ntfs-re is pakol ám ilyeneket (SystemVolumeInformation folder, RECYCLER hello mi?)

El kellene fogadni, hogy azok a fileok szükségesek bizonyos klienseknek, és akkor is tolerálni, ha azok a kisebbséghez tartoznak.

CsasZ: Nem az 1-5% miatt kell patkolni, hiszen őket nem zavarja, a 95-99% miatt kell, akik nem bírják elviselni, hogy vannak olyan rejtett fileok amiket nem az ő rendszerük pakol oda…

rog

há szerintem akit zavar a ds_store, az vadul törölgeti a thumbs.db-ket is.. 🙂 sőt azt is mackockáztatom, hogy ezek közül a nagytöbbség total commanderen ül, bekapcsolt system/rejtett fájlokkal 😀
(nekik ez a qwerty-jük)

KA_Steve

Én pl ilyen geek vagyok. Annyiból szánalmasabb még a helyzet, hogy a Windows és Total Commander helyett egy opensource klónt használok, persze bekapcsolt system/rejtett file-okkal.
Miért? Egyrészt mert fejlesztő vagyok, tudnom kell, hol milyen file van a projektemben. Másrészt mert 286-osok óta PC-n élve viszonylag power usernek számítok, egyszerűen alap, hogy a saját gépem tartalmát én kontrollálom, tudom mi miért és hol van, amennyire csak lehet, rendet tartok benne.
És roppantul *rude* dolognak tartom amikor kapok egy zip file-t tele junkkal. Akár thumbnail, akár ds_store. Fogom őket használni valaha? Soha. Akárkitől is kapok ilyen cuccot, az totál biztos lehet benne, hogy nem veszem ezeknek hasznát. Mégis átküldi, takarítgassak én utána. Minden verziónál. A kedvencem a webszerver, ott aztán pláne praktikus. Amikor pl mappák és benne lévő képek alapján automatikusan generálódik egy galéria feltételezve hogy minden file kép, ami persze nem: ott a thumbs vagy a ds_store.
Na mindegy, nem egy big deal, törli az ember és kész, de az én életemben még semmi pozitívumot nem jelentettek, viszont folyamatos kényelmetlenségek.

misran

Zila: kösz a felvilágosítást, mac-ben sajnos nem vagyok jó, talán a bsd oldala még menne :).
A thumbs-ot és barátait sem tartom jónak, le is csapom ha látok ilyet, bocsánat. A file-felhő szemléletet pedig már szokom, mert egy i5/OS alatt még csudább ez az egész, de azt továbbra sem tartom a legjobb megoldásnak hogy idegen környezetben kérdés nélkül elkezdem létrehozni a kis fileokat. Pedig lehet hogy ez a jó megoldás, de valamiért nem tudok azonosulni.
Ha elkészül az elefánt nevü OS ami minden file-hoz 50 db 10 MB-s konfig file-t generál és felnézek egy írható megosztásra vele? Tudom, erős csúsztatás, elnézést.

CsasZ

Zila: erről beszélek én is, azért kell utcaseprő, mert 1-2% tahó odaszaratja a kutyáját a járdára.
De ne akarjuk már úgy beállitani, hogy a többiek a defektesek mert nem szeretik a koszt…
(ez csak elnagyolt párhuzam és nem minősítés)