Wat zijn de resource forks in Mac OS X? Hoe kunnen ze worden gebruikt? Welke toepassingen zijn er gebruik van maken? Worden ze afgekeurd? Zijn ontwikkelaars aangemoedigd om gebruik van te maken? Zijn ze de toekomst? Waarom is er een gebrek aan up-to-date documentatie? Dit zijn slechts een handvol vragen die ik had over de onderliggende Mac OS X-bestandssysteem. Het kostte me een paar uur en honderden Google-zoekopdrachten alleen om terug te keren met tegenstrijdige informatie. Via een proces van gleaning informatie uit honderden e-mails op mailinglijsten en Usenet-groepen, door middel van zeven verouderde documentatie, en hands-on experimenten vormde ik een grof begrip van deze technologie. De volgende zijn mijn opmerkingen die samengesteld kan wel of niet correct zijn.
Ik schrijf dit onder de veronderstelling dat het beoogde systeem in kwestie is de lopende HFS + bestandssysteem .
Uitgebreide kenmerken vs resource forks
Ten eerste, presenteer ik hier een fragment van de Wikipedia-pagina op resource forks :
De resource fork is een constructie van het Mac OS-besturingssysteem gebruikt om gestructureerde gegevens op te slaan in een bestand, naast ongestructureerde gegevens opgeslagen in de data fork.
Van wat ik heb verzameld, was er een duidelijk verschil tussen de resource forks en uitgebreide attributen op een punt. Echter, dit lijkt niet langer het geval zijn als ik zal proberen uit te leggen in de volgende paragraaf. Kortom, de terminologie gebruik worden vertroebeld, en dit lijkt de bron van de meeste verwarring.
Resource forks worden afgekeurd
Er is wel een beetje lawaai te zeggen dat resource forks weggaat. Op basis van de informatie die ik gevonden, deze bewering is slechts gedeeltelijk waar. Sterker nog, resource forks al afgebouwd door middel van Apple stilletjes het veranderen van de onderliggende API implementatie. Overwegende dat deze informatie was voordien opgeslagen in de resource fork, is het nu verplaatst naar de data fork. Van wat ik kan zeggen, de meerderheid van deze gegevens manifesteert zich nu in de "bronnen" directory die kan worden gevonden in de toepassing bundels. Er is echter nog meer resource fork gegevens en dit is nu opgeslagen als een uitgebreid attribuut onder de toets "com.apple.ResourceFork."
Op dit punt moet ik interject dat het erop lijkt dat Mac OS X blijft steunen genaamd vorken. Er lijkt niet te worden eventuele beperkingen op het aantal of de grootte dat deze kunnen worden, maar ik ben niet op de hoogte van alle toepassingen die gebruik van maken. De meerderheid van de metadata lijkt te worden opgenomen in de uitgebreide attributen boom. Deze metadata is de sleutel-waarde op basis en in het algemeen zeer klein in omvang.
Hieronder is een bullet list van mijn opmerkingen.
- Apple's resource fork was gewoon een van de vele verschillende vorken dat de Mac OS X-bestandssysteem blijkbaar aankan.
- Apple's resource fork is dood, maar
- Apple API's voor de interactie met hun resource fork nu slaat deze informatie als een uitgebreide attribuut (com.apple.ResourceFork) in plaats van via een aparte vork.
- Mac OS X blijft steunen genaamd vorken.
- Ik heb niet gezien alle applicaties (Apple of anderszins) dat een vork met de naam te gebruiken dan de oorspronkelijke resource fork.
- Uitgebreide attributen worden veelvuldig gebruikt door Apple producten.
Toegang tot uitgebreide kenmerken (EA) en daarmee com.apple.ResourceFork
Apple biedt een API voor interfacing met de uitgebreide attributen, maar ze kunnen worden geopend zonder het schrijven van een applicatie met behulp van Terminal en de xattr commando. Bijvoorbeeld:-p com.apple.ResourceFork example.txt zal xattr display van de gegevens van de com.apple.ResourceFork attribuut [als hij al bestaat]. Met behulp van de @ optie met het ls commando geeft je een lijst van alle sleutels kenmerk voor elk bestand [bijv. ls-la @].
Een handige truc die nog beschikbaar is in Mac OS X Leopard [10,5] uit de dagen toen ResourceFork was opgeslagen in zijn eigen vork is met behulp van ..namedfork / RSRC. Als je niet een naam voor de vork, dan is het standaard Apple's ResourceFork. Bijvoorbeeld, example.txt / c RSR zal kat dezelfde output als xattr-p com.apple.ResourceFork example.txt.
Gotcha!
Bestand maten berekend in terminal omvatten niet de omvang van de uitgebreide attributen, waaronder de ResourceFork. Deze moet afzonderlijk worden verkregen door middel van alternatieve middelen. Bijvoorbeeld met behulp van ..namedfork / RSRC.
Zo helder als modder
Ik hoop dat dit artikel enig licht op de situatie loodsen. Uitgebreide attributen worden gebruikt nogal een beetje door Apple producten. Bijvoorbeeld, Spotlight opmerkingen opgeslagen als een uitgebreid kenmerk sleutel-waarde paar. Wanneer een bestand wordt verwijderd met behulp van Finder, een sleutel-waarde paar geschreven die aangeeft waar het bestand afkomstig is. Time Machine maakt gebruik van uitgebreide attributen voor het bijhouden van back-ups te houden, en de lijst kan worden voortgezet.
Uitgebreide kenmerken dient niet te worden gevreesd en zijn een geweldige manier om extra metadata op te slaan. Helaas, ondersteuning voor uitgebreide kenmerken is niet alomtegenwoordig. Zelfs sommige van de eigen gebundelde command line programma's van Apple niet volledig of naar behoren te ondersteunen uitgebreide attributen. Als zodanig, vanuit een oogpunt van de programmering is het wellicht verstandig om het gebruik van uitgebreide attributen te vermijden, tenzij de gegevens is van voorbijgaande aard. Alle belangrijke gegevens moeten worden opgeslagen, samen met het bestand in de data fork.
Hier is de hoop dat EA ondersteuning verbetert in de nabije toekomst!
Laat een reactie achter als de informatie die ik heb ingewonnen, is onjuist, of beter kan worden verduidelijkt.
comments… read them below or add one } (2 comments ... lees ze hieronder of voeg een )
Zijn er voordelen van deze resource fork / data fork aspect aan de appels besturingssysteem werd echter ramen doen?
Ik heb echt geen gegevens onderzocht van het NTFS-plaatsvervanger streams, dus deed ik een snelle zoekfunctie en rende het volgende artikel dat je misschien interessant vindt: http://www.symantec.com/connect/articles/what-you-need- know-over-plaatsvervanger-data-stromen-windows
Ik heb geen tijd doorgebracht met ADS op Windows, maar ik heb Apple's implementatie minder dan ideaal gevonden. Bijvoorbeeld, niet alle nutsbedrijven de hoogte zijn van of werken goed met de uitgebreide attributen. Bijvoorbeeld, de versie van rsync dat wordt geleverd met OS X bevat geen volledige ondersteuning (rsync 3 zijn dit). Dit vloeit voort waarschijnlijk uit het feit dat niet alle GNU / BSD-hulpprogramma's xattr, althans nog niet.
Ze zijn beide benaderingen in het oplossen van de metadata probleem. Helaas lijkt er enige onzekerheid omgeven hen (gaan ze om hier te zijn morgen?). Idealiter Ik zie een universele bestandssysteem ingebouwde metadata management, dat verhoogt de interoperabiliteit, maar dit is niet realistisch in de komende 5 jaar. Een meer haalbare doelstelling zou zijn om ofwel volledig laat het idee of de capaciteiten volledig te integreren in het bestandssysteem en API's met een pluggable vertaling laag beweegt zich tussen bestandssystemen te maken naadloos.