Fork zasobu (ang. Resource Fork) – fork lub sekcja pliku w klasycznym systemie operacyjnym Mac OS, został również przeniesiony do nowoczesnego macOS dla kompatybilności, używany do przechowywania strukturyzowanych danych wraz z niestrukturyzowanymi danymi przechowywanymi w forku danych.
Fork zasobu przechowuje informacje w określonej formie, zawierające szczegóły, takie jak mapy bitowe ikon, kształty okien, definicje menu i ich zawartości oraz kod aplikacji (kod maszynowy). Na przykład plik edytora tekstu może przechowywać tekst w forku danych, a jednocześnie przechowywać wszelkie osadzone obrazy w forku zasobu tego samego pliku. Fork zasobu jest używany głównie przez pliki wykonywalne, ale każdy plik może mieć fork zasobu.
Pierwotnie pomyślany i zaimplementowany przez programistę Bruce’a Horn, fork zasobu został wykorzystany do trzech celów w systemie plików Macintosh:
Fork zasobu jest zaimplementowany we wszystkich systemach plików używanych dla dysków systemowych na komputerach Macintosh (MFS, HFS i HFS Plus). Obecność forka zasobu ułatwia przechowywanie szeregu dodatkowych informacji, takich jak umożliwienie systemowi wyświetlenia właściwej ikony pliku i otwarcia go bez potrzeby rozszerzenia pliku w nazwie pliku. Podczas gdy dostęp do forka danych działa jak dostęp do pliku w dowolnym innym systemie operacyjnym – wybierz plik, wybierz przesunięcie bajtu, przeczytaj niektóre dane – dostęp do forka zasobu działa bardziej jak wyodrębnianie uporządkowanych rekordów z bazy danych. (Microsoft Windows ma również pojęcie „zasobów”, ale są one całkowicie niezwiązane z zasobami w Mac OS.)
Fork zasobu jest czasem używany do przechowywania metadanych pliku, chociaż może być również używany do przechowywania rzeczywistych danych, tak jak miało to miejsce w przypadku plików czcionek w klasycznych systemach operacyjnych Mac. Należy zauważyć, że systemy plików Macintosh mają również oddzielny obszar dla metadanych, inny niż fork danych lub zasobu. Będąc częścią katalogowego wpisu pliku, dostęp do tego jest znacznie szybszy. Jednak ilość przechowywanych tutaj danych jest minimalna, są to tylko znaczniki czasu tworzenia i modyfikacji, typ pliku i kody twórcy, długości forka i nazwa pliku. Niektóre pliki mają tylko forka zasobów. Klasyczne aplikacje 68k są jednym przykładem, w którym nawet kod wykonywalny jest zawarty w zasobach typu „KOD”. Późniejsze pliki binarne PowerPC przechowują kod wykonywalny we forku danych.
Ponieważ forki zasobu są obsługiwane tylko w systemach plików HFS i HFS Plus, nie można ich używać w systemach operacyjnych, które używają innych systemów plików. Obecnie HFS jest obsługiwany tylko przez system operacyjny Macintosha, co oznacza, że tylko komputery z systemem Mac OS mogą korzystać z forków zasobu. Nawet w systemie Mac OS nie można używać forków zasobów, jeśli Uniksowy system plików został zainstalowany. W systemie plików HFS Plus, który jest obecnie systemem najczęściej używanym w systemie Mac OS, można wprowadzić ustawienia pozwalające innym forkom oprócz forków danych i zasobu, tworzyć aplikację „multi-fork”. Ponieważ jednak forki mogą utrudniać wymianę plików z innymi systemami operacyjnymi, ta funkcja nie jest powszechnie używana. Nawet w macOS forki zasobu są rzadko używane.
Obecnie macOS obsługuje forki zasobu w Windowsowych udziałach SMB, tworząc ukryty plik ze znakami „. _” dodanymi na początku nazwy pliku, w tym samym katalogu, co plik forka danych.
Każdy zasób ma identyfikator OSType (wartość czterobajtową) i identyfikator (podpisane 16-bitowe słowo), a także opcjonalną nazwę. Istnieją standardowe typy zasobów dla okien dialogowych („DITL”), obrazów („ PICT „), dźwięków („snd”) – a nawet plików wykonywalnych („CODE”), które do czasu pojawienia się procesora PowerPC były bez wyjątku przechowywane w forku zasobów. Podprogramy do renderowania okien są przechowywane we własnym typie zasobów („WDEF”), podprogramy do renderowania menu w ich („MDEF”), a jeśli istnieje rodzaj danych, który Twoim zdaniem nie pasuje do żadnej ze standardowych kategorii, możesz równie dobrze może użyć własnego typu (np. „John”) – właściwie dowolne cztery znaki lub wartość 32-bitowa mogą służyć jako typ zasobu. Takie ustawienie umożliwiło użytkownikom łatwe dostosowanie nie tylko poszczególnych aplikacji, ale także samego systemu operacyjnego, za pomocą narzędzi takich jak ResEdit do modyfikowania zasobów pliku aplikacji lub dowolnego pliku systemowego.
W aplikacji lub innym kodzie zasoby mogą być ładowane po prostu za pomocą kombinacji ich typu, identyfikatora lub nazwy, bez względu na to, jak i gdzie są przechowywane w forku zasobu. Klient otrzymuje uchwyt do załadowanego zasobu, do którego następnie można uzyskać dostęp, jak każdych innych danych opartych na puli. Składnikiem systemu operacyjnego, który to ułatwia, jest Menedżer Zasobu. Oprócz wyodrębnienia szczegółów przechowywania danych z samych danych, Menedżer Zasobu układa również zestawy otwartych forków zasobu w stos, z ostatnio otwieranym plikiem na górze. Podczas próby załadowania zasobu, najpierw zajrzy na górę stosu (być może fork zasobu bieżącego dokumentu), następnie następny w dół (fork zasobu aplikacji), a następnie następny (fork zasobu systemowych). To ustawienie jest bardzo wydajne – pozwala lokalnym zasobom na zastąpienie bardziej globalnych niżej – tak więc aplikacja może na przykład udostępnić własne ikony lub czcionki zamiast standardowych systemowych. Pozwala również aplikacji ładować zasoby z systemu przy użyciu tego samego interfejsu API, co każdy inny zasób, bez względu na miejsce i sposób przechowywania tego zasobu – w aplikacji wszystkie zasoby są jednakowo dostępne i łatwe w użyciu. System rezerwuje identyfikatory zasobów w pewnym zakresie, aby uniknąć wynikających z tego konfliktów zasobu. Interfejsy API Menedżera Zasobu pozwalają programiście manipulować stosem i modyfikować zachowanie wyszukiwania.
Ponieważ forka zasobu można edytować za pomocą edytora zasobu, takiego jak ResEdit, można go używać do lokalizowania i dostosowywania oprogramowania. Ponadto większość edytorów zasobu umożliwia wizualną edycję danych. W macOS możliwe jest korzystanie z zasobów podczas tworzenia aplikacji. Jeśli jednak aplikacja może wymagać użycia w systemie plików UFS, można ją również skonfigurować tak, aby cały fork zasobu został przeniesiony do forka danych za pomocą ustawienia Raw Resource File. Zintegrowane środowiska programistyczne dystrybuowane za darmo przez Apple Inc., w tym MPW i Apple Developer’s Tools, zawierają kompilator o nazwie Rez. Używa on specjalnego języka, zwanego także Rez, którego można użyć do utworzenia forka zasobu poprzez kompilację kodu źródłowego. Uwzględniono również dekompilator DeRez, którego można użyć do zmiany forka zasobu z powrotem na kod Rez.
W strukturze forka zasobu znajduje się część danych zwana „mapą zasobu”, która przechowuje pozycje elementów danych zasobu. Można to wykorzystać, aby umożliwić losowy dostęp do danych zasobu na podstawie zdefiniowanych identyfikatorów i nazw. Fork zasobu można uznać za składający się zasadniczo z dwóch obiektów, mapy zasobu i samych danych zasobu, ale w rzeczywistości każdy typ danych jest strukturą hierarchiczną, która przechowuje wiele elementów danych. Format, w którym przechowywane są informacje w danych zasobu, jest definiowany na podstawie typów informacji, które są znane jako „typy zasobu”. Dane zasobu często zawierają odniesienia do innych typów danych.
W macOS forki noszą nazwę plik/..nazwanyfork/nazwaforka, np. Fork zasobu pliku IMG_0593.jpg to IMG_0593.jpg/..namedfork/rsrc. Polecenie ls obsługuje opcję -l@, która wyświetla listę forków pliku.
Forki zasobu pojawiają się jako rozszerzony atrybut com.apple. ResourceFork[1].
Wcześniej dostęp do forków zasobu był możliwy za pośrednictwem API „Menedżer Zasobu”. Ten interfejs API jest teraz przestarzały[2].
W przestarzałym interfejsie API:
API menedżera plików, takie jak PBOpenRF() również umożliwiały dostęp do forka zasobu; należy ich jednak używać tylko w aplikacjach, takich jak kopiowanie pliku – Apple zdecydowanie ostrzega przed użyciem forka zasobu jako „drugiego forka danych”.
Z interfejsu POSIX można uzyskać dostęp do forka zasobu jako nazwapliku/..nazwaforka/rsrc lub jako nazwapliku/rsrc; krótsza wersja została wycofana w Mac OS X 10.4 i całkowicie usunięta w Mac OS X 10.7[3].
Najmniejsze elementy tworzące forka zasobu nazywane są typami danych. Istnieje kilka typów danych. Po uzyskaniu dostępu do forka zasobu jego zawartość można znaleźć, odczytując go odpowiednio dla typów danych zdefiniowanych wcześniej. Umieszczenie w programie definicji określających sposób przetwarzania danych umożliwia również przechowywanie zasobu zwanych zasobami TMPL. Zastosowanie tej metody zwiększa widoczność danych podczas przeglądania za pomocą programu takiego jak ResEdit, co ułatwia późniejszą edycję. Ponieważ platforma Macintosh pochodzi z procesorów Motorola (68k i PPC), dane są serializowane na dysk w formacie big endian.
Poniżej znajduje się lista głównych typów danych w kolejności alfabetycznej.
| Typ danych | faktyczna nazwa | Opis |
|---|---|---|
| BBIT | binary bit | Reprezentuje pojedynczy bit boolean (prawda lub fałsz). Zwykle liczba BBIT musi być wielokrotnością 8. |
| BOOL | boolean | Reprezentuje wartość boolean. Składa się z 2 bajtów; 256 to prawda, a 0 to fałsz. |
| CHAR | character | Reprezentuje znak jednobajtowy. |
| CSTR | C string | Reprezentuje ciąg formy używanej w języku programowania C: zakończony zerem ciąg bajtów. |
| DLNG | decimal long word integer | Długie dziesiętne słowo (4-bajtowa liczba całkowita). Reprezentuje wartości od około – 2,1 miliarda do 2,1 miliarda. |
| HEXD | hex dump | Wskazuje, że dane od tej pozycji do końca są szesnastkowe. Służy do reprezentowania zasobu kodu lub skompresowanych danych. |
| HLNG | long word hexadecimal | Te dane są traktowane jako 4-bajtowa wartość szesnastkowa. Jest on używany między innymi do reprezentowania liczb całkowitych większych niż 2,1 miliarda, takich jak długie niepodpisane wartości w C. |
| PSTR | Pascal string | Reprezentuje ciąg Pascal, przy czym pierwszy bajt podaje długość ciągu. |
| TNAM | type name | Ciąg reprezentujący wartość, taką jak kod twórcy, który zawsze ma 4 bajty. |
| RECT | rectangle | Reprezentuje współrzędne narożników prostokąta (górny, lewy, dolny, prawy). Zawsze 8 bajtów. |
Poniższe kody typów, podobnie jak powyższe typy danych, są używane jako identyfikatory typu dla więcej niż samych forków zasobu: służą one do samodzielnej identyfikacji pliku, opisu danych w schowku i wielu innych.
Zauważ, że typy muszą mieć 4 bajty, więc typy takie jak snd i STR faktycznie mają spację (0x20) na końcu.
| Nazwa typu zasobu | faktyczna nazwa | Opis |
|---|---|---|
| alis | alias | Przechowuje alias w innym pliku, w forku zasobu pliku w którym ustawiony jest bit atrybutu „alias” |
| ALRT | alert | Określa kształt pola ostrzeżenia aplikacji |
| APPL | application | Przechowuje informacje o aplikacji |
| BNDL | bundle | Definiuje dane, takie jak ikona typu pliku używana w aplikacji |
| cicn | color icon | Definiuje ikonę koloru używaną w danych |
| clut | color look-up table | Definiuje paletę kolorów używaną w danych |
| CNTL | control | Definiuje szczegóły komponentu umieszczonego w oknie |
| CODE | code resource | Przechowuje kod maszynowy dla programu |
| CURS | cursor | Określa kształt kursora monochromatycznego (kwadrat 8 × 8 bitów) |
| DITL | dialog item list | Definiuje komponent okna |
| DLOG | dialog | Określa kształt okna dialogowego dla aplikacji |
| FREF | file reference | Definiuje typ pliku obsługiwany przez aplikację |
| hfdr | icon balloon help | Definiuje zawartość i kształt dymku pomocy wyświetlanego, gdy kursor znajdzie się nad plikiem w Finderze |
| icl8 | 8 bit icon list | Definiuje ikonę wyświetlaną w Finderze |
| icns | 32 bit icon list | Definiuje ikonę wyświetlaną w Finderze |
| ICON | ICON | Definiuje element monochromatyczny używany w danych |
| kind | file description | Definiuje opis typu pliku |
| MBAR | menu bar | Definiuje menu i pasek menu dla aplikacji |
| MDEF | menu definition | Definiuje menu dla aplikacji. Może być również używany do definiowania menu o złożonych kształtach, takich jak palety kolorów. |
| MENU | menu | Definiuje pozycje menu w aplikacji |
| MooV | movie | Przechowuje film QuickTime |
| open | open | Definiuje typ pliku, który aplikacja może otworzyć |
| PICT | picture | Przechowuje obraz PICT zawarty w pliku |
| PREF | preference | Przechowuje ustawienia środowiska dla aplikacji |
| snd | sound | Przechowuje dźwięk użyty w pliku |
| STR | string | Przechowuje ciąg lub dane szesnastkowe użyte w pliku |
| STR# | string list | Przechowuje wiele ciągów używanych w pliku |
| styl | style | Definiuje informacje o stylu, takie jak czcionka, kolor i rozmiar tekstu |
| TEXT | text | Przechowuje tekst |
| TMPL | template | Definiuje format danych zasobu |
| vers | version | Określa wersję lub region użytkowania pliku |
| WDEF | window definition | Definiuje okno aplikacji. Okna o nieokreślonym kształcie można również zdefiniować. |
| WIND | window | Określa kształt okna aplikacji |
Złożoność programowania przy użyciu forków zasobu doprowadziła do problemów ze zgodnością podczas uzyskiwania dostępu do innych systemów plików za pośrednictwem protokołów udostępniania plików, takich jak AFP, SMB, NFS i FTP, podczas przechowywania na woluminach innych niż HFS lub podczas przesyłania plików do innych systemów w inny sposób (takich jak e-mail). Protokół AFP natywnie obsługuje Forki Zasobu, więc forki zasobu są zazwyczaj przesyłane do tych woluminów w stanie niezmienionym i przechowywane przez serwer w sposób przezroczysty dla klientów. Protokół SMB obsługuje system metadanych plików podobny do forków Macintosh zwanych alternatywnymi strumieniami danych (dalej ADS). macOS do wersji Mac OS X 10.6 nie obsługiwał przechowywania forków zasobu w ADS na woluminach SMB. W poprzednich wersjach systemu operacyjnego, w tym w zaktualizowanych wersjach 10.6, tę funkcję można włączyć za pomocą zmiany parametrów lub poprzez utworzenie specjalnego pliku[4].
Sieciowe protokoły udostępniania plików, takie jak NFSv3 i FTP, nie mają koncepcji metadanych plików, więc nie ma możliwości natywnego przechowywania forków zasobu. Dotyczy to również zapisu do niektórych typów lokalnych systemów plików, w tym UFS, oraz na woluminach SMB, w których obsługa alternatywnego strumienia danych nie jest włączona. W takich przypadkach macOS przechowuje metadane i forki zasobu przy użyciu techniki o nazwie AppleDouble, w której Fork danych jest zapisywany jako jeden plik, a Fork zasobu i metadane są zapisywane jako osobny plik poprzedzony znakiem „. _” Konwencja nazewnictwa. Na przykład: PrzykladowyPlik.psd zawierałby forka danych, a. _PrzykladowyPlik.psd zawierałby forka zasobu i metadane.
Mogą pojawić się problemy ze zgodnością, ponieważ macOS będzie obsługiwał przechowywanie forków zasobu w różny sposób, w zależności od wersji macOS, ustawień i typu systemu plików. Na przykład w sieci SMB z mieszanką klientów 10.5 i 10,6. Świeżo zainstalowany klient 10.6 będzie szukać i przechowywać forki zasobu na woluminie SMB w ADS, ale klient 10.5 (domyślnie) zignoruje ADS i użyje formatu AppleDouble do obsługi forków. Jeśli serwer plików obsługuje zarówno AFP, jak i NFS, klienci korzystający z NFS będą przechowywać pliki w formacie AppleDouble, podczas gdy użytkownicy AFP będą przechowywać natywny forka zasobu. W takich przypadkach zgodność można czasem zachować, zmuszając klientów do używania lub nieużywania formatu AppleDouble.
Wiele serwerów plików obsługujących AFP nie obsługuje natywnie forków zasobu w swoich lokalnych systemach plików. W takich przypadkach forki mogą być przechowywane w specjalny sposób, taki jak specjalnie nazwane pliki, specjalne katalogi, a nawet alternatywne strumienie danych.
Kolejnym wyzwaniem jest zachowanie forków zasobu podczas przesyłania plików przy użyciu aplikacji nieobsługujących forków zasobu lub określonych metod przesyłania, w tym poczty e-mail i FTP. Aby to obsłużyć, utworzono wiele formatów plików, takich jak MacBinary i BinHex. Narzędzia systemowe wiersza poleceń SplitForks i FixupResourceForks umożliwiają ręczne spłaszczanie i scalanie wideł zasobu. Ponadto serwer plików, który chce prezentować systemy plików klientom Macintosh, musi obsługiwać forka zasobu, a także forka danych plików; Serwery UNIX zapewniające obsługę AFP zazwyczaj implementują to z ukrytymi katalogami.
Starsze aplikacje napisane przy użyciu Carbon API mogą mieć problem z przeniesieniem na obecne komputery Mac z procesorami Intel. Podczas gdy Menedżer Zasobu i system operacyjny wiedzą, jak poprawnie dokonać deserializacji danych dla typowych zasobu, takich jak „snd” lub „MooV”, zasoby utworzone przy użyciu zasobu TMPL muszą zostać ręcznie zamienione bajtami, aby zapewnić interoperacyjność plików między wersjami aplikacji opartymi na PPC i Intel. (Chociaż mapa zasobu i inne szczegóły implementacji są big endianami, sam Menedżer Zasobu nie ma żadnej wiedzy na temat zawartości zasobu ogólnego, a zatem nie może automatycznie zamieniać bajtów.)
Do czasu pojawienia się systemu Mac OS X 10.4 standardowe narzędzia wiersza poleceń systemu UNIX w systemie macOS (takie jak cp i mv) nie szanowały forków zasobu. Aby skopiować pliki z forkami zasobu, trzeba było użyć ditto lub CpMac i MvMac.
Koncepcja menedżera zasobu dla obiektów graficznych w celu oszczędzania pamięci powstała w pakiecie OOZE na Alto w Smalltalk-76.[5] Koncepcja jest obecnie w dużej mierze uniwersalna we wszystkich nowoczesnych systemach operacyjnych. Jednak koncepcja forka zasobu jest charakterystyczna dla komputerów Macintosh. Większość systemów operacyjnych używa pliku binarnego zawierającego zasoby, który jest następnie „przyczepiany” do końca istniejącego pliku programu. To rozwiązanie jest stosowane na przykład w systemie Microsoft Windows, a podobne rozwiązania są stosowane w systemie X Window, chociaż zasoby często są pozostawione jako osobny plik.
Windowsowy NTFS może obsługiwać forki (a więc może być serwerem plików dla plików Mac), natywna funkcja zapewniająca obsługę nazywana jest alternatywnym strumieniem danych (ADS). Funkcje systemu operacyjnego Windows (takie jak standardowa karta Podsumowanie na stronie Właściwości plików innych niż Office) i aplikacje Windows z nich korzystają, a Microsoft opracowywał system plików nowej generacji, który ma taką funkcję jako podstawę.
Wczesne wersje BeOS zaimplementowały bazę danych w systemie plików, która może być używana w sposób analogiczny do forka zasobu. Problemy z wydajnością doprowadziły do zmiany w późniejszych wersjach systemu złożonych atrybutów systemu plików. W ramach tego systemu zasoby były obsługiwane w sposób nieco bardziej analogiczny do komputera Mac.
AmigaOS nie używa forkowanych plików. Pliki wykonywalne są wewnętrznie podzielone na modułową strukturę dużych elementów (hunk) zdolnych do przechowywania kodu, danych i dodatkowych informacji. Podobnie pliki danych i projektów mają strukturę chunk’a skodyfikowaną w standardzie IFF. Inne typy plików są przechowywane podobnie jak u innych systemów operacyjnych. Chociaż nie jest to dokładnie fork zasobu, AmigaOS przechowuje metadane w plikach zwanych plikami.info. Pliki.info można rozpoznać po rozszerzeniu.info; na przykład, jeśli zapiszesz projekt na dysku, zostaną zapisane dwa pliki, MyProject i MyProject.info. MyProject byłby rzeczywistymi danymi projektu, a MyProject.info zawierałby ikonę projektu, informacje o tym, który program jest potrzebny do otwarcia projektu (ponieważ w AmigaOS nie ma powiązania aplikacji), specjalne opcje projektu i wszelkie komentarze użytkowników. Pliki.info są niewidoczne na pulpicie Amigi (Workbench). Ikona na pulpicie, zaczerpnięta z samego.info, jest metaforą interfejsu, poprzez którą użytkownik wchodzi w interakcję zarówno z samym projektem, jak i powiązanym z nim plikiem.info. Okno dialogowe dostępne po kliknięciu ikony prawym przyciskiem myszy pozwala użytkownikowi zobaczyć i zmodyfikować metadane obecne w pliku.info. Pliki.info mogą być widoczne jako pojedyncze pliki w interfejsie wiersza poleceń lub w menedżerze plików. Nowoczesne klony AmigaOS (AROS, MorphOS i AOS4) dziedziczą strukturę (wraz z metadanymi) plików.info starszych wersji AmigaOS, a także mogą akceptować standardowe pliki graficzne PNG jako mapy bitowe ikon w swoich plikach.info.
Systemy operacyjne NeXT NeXTSTEP i OPENSTEP, ich następca, macOS i inne systemy, takie jak RISC OS, zaimplementowały inne rozwiązanie. W tych systemach zasoby są pozostawione w oryginalnym formacie, na przykład obrazy są dołączane jako kompletne pliki TIFF zamiast być zakodowane w jakimś kontenerze. Zasoby te są następnie umieszczane w katalogu wraz z kodem wykonywalnym i „surowymi danymi”. Katalog (zwany „pakietem” lub „katalogiem aplikacji”) jest następnie przedstawiany użytkownikowi jako sama aplikacja. To rozwiązanie zapewnia taką samą funkcjonalność jak fork zasobu, ale umożliwia łatwą manipulację zasobami przez dowolną aplikację – „edytor zasobu” (jak ResEdit) nie jest potrzebny. Z interfejsu wiersza poleceń pakiet wydaje się być normalnym katalogiem. To podejście nie było opcją w klasycznym systemie Mac OS, ponieważ system plików (MFS) nie obsługiwał oddzielnych ścieżek katalogowych. Po włączeniu obsługi plików katalogu w systemie Mac OS z systemem plików HFS, fork zasobu został zachowany. macOS zachowuje klasyczny interfejs API Menedżera Zasobu jako część bibliotek Carbon dla kompatybilności wstecznej. Jednak same zasoby można teraz przechowywać w osobnych plikach danych w systemie plików – Menedżer zasobu ukrywa teraz tę zmianę implementacji przed kodem klienta.