Partycje
Rozwiązaniem problemu było zorganizowanie danych w przyjaznej dla użytkownika strukturze logicznej. Pierwszym krokiem w zarządzaniu strukturą logiczną dysków (lub ich zespołów widzianych jako jedna całość – macierzy RAID) jest ich podział na logicznie wydzielone części – partycje. Podział dysku na partycje opisuje tablica partycji znajdująca się w pierwszym sektorze dysku — głównym sektorze rozruchowym (MBR – Master Boot Record). Tablica ta pozwala na utworzenie maksymalnie czterech partycji.
Cztery partycje nie zawsze wystarczają. Dlatego pojawił się podział na partycje podstawowe (opisywane w MBRze wprost) i partycje rozszerzone, na których mogą być tworzone woluminy logiczne. Po założeniu od 1 do 3 partycji podstawowych można utworzyć partycję rozszerzoną, którą można później dzielić na praktycznie nieograniczoną liczbę woluminów logicznych. Partycja rozszerzona zaczyna się od struktury logicznej zwanej Secondary MBR, zawierającej kolejną tablicę partycji. W tej tablicy umieszczamy rekord opisujący wolumin logiczny oraz kolejną partycję rozszerzoną obejmującą obszar do końca dysku, która znów zaczyna się od Secondary MBRu. I tak aż do wyczerpania miejsca na dysku.
Innym rozwiązaniem problemu jest użycie tablicy GPT (GUID Partition Table, przy czym GUID oznacza Globally Unique Identifier – identyfikator unikatowy globalnie). Wbrew szeroko rozpowszechnionemu przekonaniu, GPT nie zastępuje MBRu, a stanowi jego roz-szerzenie. MBR wciąż znajduje się w pierwszym sektorze dysku, wciąż zawiera tablicę partycji, jednak w tej tablicy opisuje tylko jedną partycję z kodem typu 0xEE, obejmującą całą dostępną przestrzeń adresową. Jest to zabezpieczenie na wypadek podłączenia dysku pod systemem nieobsługującym GPT. Dzięki temu wpisowi taki system będzie wiedział, że dysk nie jest pusty i że coś się na nim znajduje.
W kolejnym sektorze znajduje się nagłówek tablicy GPT, a dalej – 32 sektory tablicy pozwalającej na opisanie 128 partycji. Liczba dostępnych partycji może być zwiększona w przyszłości przez zwiększenie rozmiaru tablicy. Kopia tablicy GPT znajduje się na końcu dysku, co ułatwia odzyskiwanie danych w przypadku uszkodzenia początkowych sektorów dysku.
Tablica GPT rozwiązuje jeszcze jeden problem. Dzięki 64- bitowemu adresowaniu pozwala na obsługę partycji na dyskach większych od 2 TB. Wystarczy pomnożyć maksymalną liczbę 32-bitową 0xFFFFFFFF przez rozmiar sektora 0x200 [B], by przekonać się, dlaczego posługująca się 32-bitowymi adresami tablica partycji z MBRu może adresować maksymalnie 2 TB – 1 sektor.
Systemy plików
Dane stanowiące spójną, zorganizowaną całość tworzą plik, który może być traktowany, jako obiekt jednostkowy zarówno przez użytkownika, jak i przez system operacyjny. Jednak dysk nie rozumie tego, czym jest plik. Wciąż jedynie może odczytać lub zapisać dowolne sektory zgodnie z otrzymanym żądaniem, a więc musi istnieć coś, co wskaże dyskowi właściwe sektory, gdy wybieramy określony plik.
Tym czymś są systemy plików. Pozwalają one użytkownikowi zapomnieć o adresacji sektorowej przechowując informację o położeniu plików. Struktury systemu plików zwane metadanymi opisują także nazwy plików, ich położenie w strukturze logicznej katalogów (zwanych też folderami), uprawnienia dostępu, różne parametry czasu (np. utworzenia, modyfikacji pliku) oraz inne atrybuty.
Systemy plików zwykle nie posługują się adresacją sektorową, ale większymi wewnętrznymi jednostkami, zwanymi, w zależności od nomenklatury przyjętej w danym systemie, klastrami lub blokami. W systemach plików środowiska uniksowo – linuksowego występują też grupy łączące wiele bloków oraz fragmenty, mogące być częścią bloków. W praktyce fragmentów od dawna nie używa się do adresowania danych i w parametrach ich rozmiar określa się jako równy rozmiarowi bloku.
Oczywiście różne systemy plików różnią się między sobą i niekoniecznie muszą obsługiwać te same atrybuty plików. Np. stosunkowo proste systemy plików z rodziny FAT nie pozwalają na identyfikację właściciela pliku oraz nadawania plikom praw dostępu, a pierwsza wersja FAT12 nie pozwalała na tworzenie struktury katalogów. Był tylko jeden katalog główny, w którym umieszczano wszystkie pliki.
W większości systemów plików jednak występuje możliwość tworzenia struktury katalogów, a za przyporządkowanie pliku do danego katalogu odpowiada umieszczenie opisu tego pliku w konkretnym katalogu (w większości systemów plików) lub umieszczenie informacji odwołującej się do danego katalogu w opisie pliku. Drugi z tych wariantów jest wykorzystywany w systemie plików NTFS, gdzie o przynależności pliku do konkretnego katalogu decyduje informacja w rekordzie MFT opisującym ten plik.
Przenoszenie pliku z katalogu jest operacją na metadanych. Plik zostaje fizycznie w tym samym miejscu, w którym był. Przenoszony lub zmieniany jest jedynie jego opis. Do tego samego pliku metadane systemu plików mogą się odwoływać wielokrotnie wskazując wprost położenie na partycji (dowiązanie twarde) lub wskazując nazwę i ścieżkę dostępu (dowiązanie symboliczne). Innym istotnym zadaniem systemów plików jest określanie zajętego (zaalokowanego w strukturach logicznych) i wolnego miejsca na partycji. System plików wiedząc o tym, że dany obszar partycji jest zajęty przez plik, nie pozwoli na jego nadpisanie kolejnymi informacjami.
W przypadku dużych partycji dobrze jest mieć możliwość szybkiego ustalenia, gdzie jest wolne miejsce, w którym można umieścić nowy plik bez konieczności analizy wszystkich metadanych. Pomocne w tym są wykorzystywane przez wiele systemów plików bitmapy – struktury opisujące klastry partycji w ten sposób, że każdemu z nich odpowiada jeden bit. Zwykle bity opisujące zajęte klastry przyjmują wartość 1, a wolne – 0. Bitmapy są też niezwykle przydatne przy wykonywaniu kopii posektorowych, gdyż pozwalają ograniczyćczas i ryzyko ich wykonywania dzięki możliwości ominięcia wolnych obszarów.
Pliki
Plik jest czymś odrębnym od jego opisu, który może się zmieniać niezależnie od zawartości. Tak się dzieje, kiedy, na przykład, zmieniamy nazwę pliku. Zmiana nazwy zdjęcia kotka z „kot.jpg” na „pies.jpg” nie spowoduje żadnych zmian w treści zdjęcia. Tak samo zmiana rozszerzenia (ostatniego członu nazwy pliku po kropce) używanego do określenia typu pliku nie spowoduje, że typ pliku się zmieni.
Zmiana nazwy na „kot.pdf” nie przekonwertuje zdjęcia do pdfu, próba otwarcia tego pliku w programie Acrobat Reader lub innym programie do odczytu pdfów zakończy się komunikatem o nieprawidłowym formacie pliku. Ale jeśli wymusimy otwarcie tego pliku przez dowolną przeglądarkę grafiki, zdjęcie otworzy się nam poprawnie, pomimo zmienionego rozszerzenia.
Niekiedy pliki mogą w swej wewnętrznej strukturze skrywać niespodzianki. Zmień rozszerzenie pliku.docx,.xlsx lub.pptx na.zip i spróbuj rozpakować. Co jest w środku? Dlaczego takie coś jest możliwe? I dlaczego tym razem program nie zwrócił komunikatu o nieprawidłowym formacie pliku?
Pliki też mają swoją wewnętrzną strukturę.
Większość typów plików zaczyna się od określonej sygnatury i właśnie po tej sygnaturze programy mogą sprawdzić, czy mają do czynienia z obsługiwanym przez nie typem pliku. Sygnatury są też wykorzystywane do wyszukiwania plików przez programy odzyskujące dane. W przypadkach rozległych uszkodzeń metadanych systemu plików to może być jedyna droga, by odzyskać cokolwiek.
Pliki odzyskiwane na podstawie sygnatur mają nazwy generowane przez program. Zwykle jest to numer sektora, w którym znajduje się sygnatura i skorelowane z nią rozszerzenie. Rozmiar odzyskiwanych plików może się istotnie różnić od pierwotnego rozmiaru odzyskiwanych plików. Niektóre typy plików, np.,pdf, mają sygnatury końca pliku, ale większość plików ich nie ma. Dlatego program często nie potrafi znaleźć końca pliku i umieszcza w nim wszystkie sektory aż do napotkania kolejnej sygnatury lub do końca nośnika. Pliki odzyskiwane po sygnaturach często są uszkodzone.
Dzieje się tak zwłaszcza w przypadku, gdy pliki były pofragmentowane. Uszkodzenie lub utrata meta-danych nie pozwala na odnalezienie i ułożenie we właściwej kolejności wszystkich klastrów zawierających ten plik. Dlatego program w takiej sytuacji odnajduje jedynie pierwszy fragment pliku, niekiedy zanieczyszczony fragmentami innych plików. Innym powodem pojawienia się w wynikach uszkodzonych plików są pozostałości starych plików, które zostały usunięte w strukturach logicznych, ale pozostały fizycznie na dysku. Często takie pliki ulegają uszkodzeniu przez częściowe nadpisanie, gdyż miejsce, które zajmują z punktu widzenia struktur logicznych jest miejscem wolnym. Możliwe jest też pojawienie się fałszywych wyników, kiedy w odpowiednim miejscu znajduje się wartość przypadkowo zbieżna z określoną sygnaturą. Niektóre typy plików nie mają żadnych sygnatur ani elementów tworzących wewnętrzną strukturę.
Przeważnie dotyczy to plików tekstowych, takich, jak pliki.txt, czy skrypty Pythona. W przypadku takich plików o tym, że są one plikami tego, a nie innego rodzaju w 100 % odpowiada opis w metadanych odnoszący się do wskazanego w tym opisie miejsca na partycji. Odzyskiwanie takich plików po sygnaturach nie jest możliwe, ale można próbować ich szukać wpisując w wyszukiwarkę hex-edytora ciągi znaków, jakich się w tych plikach spodziewamy. Przeważnie są to pliki łatwo czytelne w ASCII i na tyle małe, że po odnalezieniu zadanego ciągu znaków możemy manualnie zidentyfikować i wykopiować potrzebne sektory.
