Fork (system plików)

Z Wikipedii, wolnej encyklopedii

W komputerowym systemie plików fork to zestaw danych powiązanych z obiektem systemu plików. Systemy plików bez forków dopuszczają tylko jeden zestaw danych dla zawartości, podczas gdy systemy plików z forkami dopuszczają wiele takich treści. Każdy niepusty plik musi mieć co najmniej jeden fork, często typu domyślnego, i w zależności od systemu plików plik może mieć jeden lub więcej powiązanych forków, które z kolei mogą zawierać podstawowe dane zintegrowane z plikiem lub po prostu metadane.

W przeciwieństwie do atrybutów rozszerzonych, podobnej funkcji systemu plików, która zwykle ma stały rozmiar, forki mogą mieć zmienny rozmiar, być może nawet większe niż główny fork danych pliku. Rozmiar pliku to suma rozmiarów każdego forka.

Alternatywy[edytuj | edytuj kod]

W systemach plików bez forków można zamiast tego użyć wielu oddzielnych plików, które są ze sobą powiązane, w szczególności plików pomocniczych dla metadanych. Jednak połączenie między tymi plikami nie jest automatycznie zachowywane przez system plików i musi być obsługiwane przez każdy program, który działa na plikach. Inną alternatywą jest plik kontenera, który przechowuje dodatkowe dane w danym formacie pliku lub plik archiwum, który pozwala na przechowywanie kilku plików i metadanych w pliku (w jednym forku). Wymaga to, aby programy przetwarzały plik kontenera lub plik archiwum, zamiast systemu plików obsługującego forki. Te alternatywy wymagają dodatkowej pracy programów korzystających z danych, ale korzystają z przenośności do systemów plików, które nie obsługują forków.

Implementacje[edytuj | edytuj kod]

Apple[edytuj | edytuj kod]

Forki systemu plików są powiązane z systemem plików AppleHFS[1]. System plików HFS firmy Apple i oryginalny system plików Macintosha MFS umożliwiły obiektowi systemu plików posiadanie dwóch rodzajów forków: fork danych i fork zasobu.

Fork zasobu został zaprojektowany do przechowywania nieskompilowanych danych, które byłyby używane przez graficzny interfejs użytkownika (GUI) systemu, takich jak lokalizowalne ciągi tekstowe, ikona pliku do użycia przez Finder lub menu i okna dialogowe powiązane z aplikacją[2]. Ta funkcja była jednak bardzo elastyczna, dlatego znaleziono dodatkowe zastosowania, takie jak podział dokumentu edytora tekstu na treść i prezentację, a następnie przechowywanie każdej części w osobnych zasobach. Ponieważ skompilowany kod oprogramowania był również przechowywany w zasobie, często aplikacje składałyby się tylko z forka zasobu i bez forka danych.

Jedną z najbardziej niejasnych funkcji HFS+ jest to, że plik może zawierać dowolną liczbę niestandardowych "nazwanych forków" oprócz tradycyjnych forków danych i zasobu. Ta funkcja została w dużej mierze nieużywana, ponieważ Apple nigdy nie dodało jej obsługi w systemach Mac OS 8.110.3.9. Począwszy od wersji 10.4 dokonano częściowej implementacji w celu obsługi rozszerzonych atrybutów wbudowanych Apple.

Do wersji Mac OS X 10.4 użytkownicy korzystający z narzędzi wiersza polecenia Unix (takich jak tar) zawartych w Mac OS X ryzykowali utratę danych, ponieważ narzędzia te nie były aktualizowane do obsługi forków zasobu plików do wersji 10.4.[3]

Novell[edytuj | edytuj kod]

Począwszy od 1985 r. system plików Novell NetWare (NWFS) i jego następca, Novell Storage Services (NSS), zostały zaprojektowane od podstaw z wykorzystaniem różnych metod przechowywania metadanych pliku. Niektóre metadane znajdują się w Novell Directory Services (NDS), niektóre są przechowywane w strukturze katalogów na dysku, a niektóre są przechowywane, jak to określa Novell, w |wielu strumieniach danych" z samym plikiem. Wiele strumieni danych pozwala również klientom Macintosh na łączenie się z serwerami NetWare i korzystanie z nich.

Microsoft[edytuj | edytuj kod]

NTFS, system plików wprowadzony wraz z Windows NT 3.1, obsługuje forki systemu plików znane jako alternatywne strumienie danych (ADS)[4]. ReFS, nowy system plików wprowadzony z Windows Server 2012, początkowo nie obsługiwał ADS[5][6][7], ale w Windows 8.1 64-bit i Server 2012 R2 wsparcie dla ADS, o długości do 128 KB, zostało dodane do ReFS.[8]

ADS pierwotnie miał na celu dodanie kompatybilności z istniejącymi systemami operacyjnymi obsługującymi forki[potrzebny przypis]. Program komputerowy może zostać skierowany do otwarcia ADS poprzez podanie nazwy ADS po znaku dwukropka (:) umieszczonego bezpośrednio za ścieżką pliku[9]. Pomimo wsparcia, większość programów systemowych, w tym Eksplorator Windows i polecenie dir (w wersji sprzed Windows Vista), ignoruje ADS. Eksplorator Windows kopiuje ADS i ostrzega, gdy docelowy system plików ich nie obsługuje, ale podaje tylko rozmiar głównego strumienia jako rozmiar pliku oraz nie pozwala na wyświetlanie strumieni plików ani folderów. Od systemu Windows Vista polecenie dir obsługuje już wyświetlanie ADS – należy użyć parametru /r.[10] Program Windows PowerShell w wersji 3.0 i nowszej również obsługuje manipulowanie ADS.[11]

Użycie[edytuj | edytuj kod]

Windows 2000 używa ADS do przechowywania miniatur w plikach obrazów oraz do przechowywania informacji podsumowujących (takich jak tytuł i autor) w dowolnym pliku, bez zmiany głównego strumienia[12][13]. W systemie Windows XP Microsoft zdał sobie sprawę, że ADS jest podatny na utratę, gdy pliki zawierające je zostaną przeniesione z woluminów NTFS; dlatego system Windows XP przechowuje je w głównym strumieniu, ilekroć obsługuje go format pliku. System Windows Vista przestał obsługiwać dodawanie informacji podsumowujących, ponieważ Microsoft zdecydował, że są one zbyt wrażliwe, aby mogły je obsługiwać ADS.[14] Ale wykorzystanie ADS do innych celów nie przestało. Dodatek Service Pack 2 dla systemu Windows XP wprowadził usługę wykonywania załączników, która przechowuje szczegółowe informacje o pochodzeniu pobranych plików w ADS o nazwie identyfikator strefy (zone identifier), aby chronić użytkowników przed pobranymi plikami, które mogą stanowić ryzyko[15]. Internet Explorer i Windows 8 rozszerzyły tę funkcję o SmartScreen[16]. Internet Explorer używa również ADS do przechowywania favicon w plikach skrótów internetowych[9].

Sun[edytuj | edytuj kod]

Solaris wersji 9 i późniejszych zezwala plikom na forki. Forki w Solarisie nazywane są atrybutami rozszerzonymi, chociaż nie mieszczą się w zwykłym znaczeniu "atrybutu rozszerzonego". Maksymalny rozmiar rozszerzonego atrybutu typu Solaris jest taki sam jak maksymalny rozmiar pliku i są one odczytywane i zapisywane w taki sam sposób jak pliki. Wewnętrznie są one faktycznie przechowywane i dostępne tak jak normalne pliki, więc ich własność i uprawnienia mogą różnić się od praw do pliku nadrzędnego. Podkatalogi są administracyjnie[potrzebny przypis] wyłączone, więc ich nazwy nie mogą zawierać znaków "/".

Atrybuty rozszerzone w Network File System w wersji 4 są podobne do atrybutów rozszerzonych w stylu Solaris.

Możliwe zagrożenia bezpieczeństwa i utraty danych[edytuj | edytuj kod]

Gdy system plików obsługuje różne forki, aplikacje powinny o nich wiedzieć, w przeciwnym razie mogą wystąpić zagrożenia bezpieczeństwa. Zezwolenie starszemu oprogramowaniu na dostęp do danych bez odpowiednich shimów jest głównym winowajcą takich problemów[potrzebny przypis]. Jeśli różne narzędzia systemowe (eksplorator dysku, oprogramowanie antywirusowe, archiwizatory itp.) nie są świadome różnych forków, mogą wystąpić następujące problemy:

  • Użytkownik nigdy nie pozna obecności żadnego alternatywnego forka ani całkowitego rozmiaru pliku, tylko głównego forka danych.
  • Wirusy komputerowe mogą ukrywać się w alternatywnych forkach w systemie Windows i nigdy nie zostaną wykryte, jeśli oprogramowanie antywirusowe nie rozpoznaje forków.
  • Dane mogą zostać utracone podczas wysyłania plików przez nieświadome kanały, takie jak e-mail, systemy plików bez obsługi forków, a nawet podczas kopiowania plików między systemami plików z obsługą forks, jeśli program, który utworzył kopię, nie obsługuje forków lub gdy kompresowanie plików za pomocą oprogramowania, które nie obsługuje forków.

Zobacz też[edytuj | edytuj kod]

Przypisy[edytuj | edytuj kod]

  1. File Forks (IM: F) [online], developer.apple.com [dostęp 2020-03-15] [zarchiwizowane z adresu 2004-09-01].
  2. Folklore.org: The Grand Unified Model (1) - Resources [online], www.folklore.org [dostęp 2020-03-13].
  3. Zarchiwizowana kopia. [dostęp 2020-03-13]. [zarchiwizowane z tego adresu (2008-02-25)].
  4. Files and Clusters - Win32 apps | Microsoft Docs [online], docs.microsoft.com [dostęp 2020-03-13] (ang.).
  5. Archived MSDN and TechNet Blogs | Microsoft Docs [online], blogs.msdn.com [dostęp 2020-03-13] [zarchiwizowane z adresu 2012-01-17] (ang.).
  6. Microsoft goes public with plans for its new Windows 8 file system | ZDNet [online], www.zdnet.com [dostęp 2020-03-13] (ang.).
  7. Windows Server 2012: Does ReFS replace NTFS? When should I use it? – Martin Lucas, TechNet
  8. Resilient File System Overview | Microsoft Docs [online], technet.microsoft.com [dostęp 2020-03-13] (ang.).
  9. a b Archived MSDN and TechNet Blogs | Microsoft Docs [online], blogs.msdn.com [dostęp 2020-03-13] [zarchiwizowane z adresu 2013-09-13] (ang.).
  10. Use Vista's DIR command to display alternate data streams - B# .NET Blog [online], bartdesmet.net [dostęp 2020-03-13] [zarchiwizowane z adresu 2009-05-26] (ang.).
  11. FileSystem Provider [online], microsoft.com [dostęp 2024-04-23] [zarchiwizowane z adresu 2014-07-17] (ang.).
  12. Archived MSDN and TechNet Blogs | Microsoft Docs [online], blogs.msdn.com [dostęp 2020-03-13] (ang.).
  13. Indexing service adds data streams to image files [online], microsoft.com [dostęp 2024-04-23] [zarchiwizowane z adresu 2007-02-09] (ang.).
  14. Archived MSDN and TechNet Blogs | Microsoft Docs [online], blogs.msdn.com [dostęp 2020-03-13] (ang.).
  15. Demo of "Attachment Execution Service internals" in Windows XP SP2 and Windows Server 2003 SP1 - B# .NET Blog [online], community.bartdesmet.net [dostęp 2020-03-13] [zarchiwizowane z adresu 2006-11-04] (ang.).
  16. Archived MSDN and TechNet Blogs | Microsoft Docs [online], blogs.msdn.com [dostęp 2020-03-13] (ang.).

Linki zewnętrzne[edytuj | edytuj kod]