(poniższy tekst ukazał się w Software Developers Journal)

Definicję czym jest wirtualny system plików możemy sprowadzić do prostego sformułowania: dany zasób „udaje” zwykły, lokalny system plików tak, że możemy korzystać z niego w sposób przeźroczysty, używając tych samych metod i poleceń co w przypadku prawdziwego systemu plików.

Każdy z tych zasobów ma własną, wewnętrzną metodę przechowywania i zarządzania plikami, zaś system VFS jest warstwą abstrakcji oferującą ujednolicony interfejs dostępowy. Jakkolwiek temat może wydawać się odległy, okazuje się że często korzystamy z tego typu rozwiązań na codzień:

• dostęp do archiwów typu zip czy rar oferowany przez TotalCommander

• TrueCrypt i jego wirtualne woluminy

Artykuł ten jest pierwszym z cyklu poświęconego tworzeniom zaawansowanych rozwiązań w oparciu o VFSy i język Tcl. W tym odcinku zyskamy solidne podstawy na temat architektury Tcla w kontekście wirtualnych systemów plików, oraz poznamy kilka gotowych implementacji i ich zastosowania.

Wszystkie przykłady w niniejszym artykule były uruchamiane z użyciem dystrybucji ActiveTcl w wersji 8.5.x.

System plików w środowisku Tcl

Od początku istnienia język Tcl/Tk posiada funkcje pozwalające na dostęp do plików – takie jak polecenie open, file czy glob. Od wersji 7.x interpreter Tcla posiada własne API dostępu do systemu plików z poziomu języka C, przykrywające funkcje systemowe, co pozwoliło na stworzenie warstwy abstrakcji. 

 W roku 1999, równocześnie z opublikowaniem wersji Tcl 8.0 powstał komercyjny pakiet TclPro, a wraz nim narzędzie prowrap pozwalające na „pakowanie” programów napisanych za pomocą skryptów Tclowych do pojedynczych plików wykonywalnych. Rozwiązanie to stało się bardzo popularne i każda następna wersja języka Tcl oferowała coraz lepsze wsparcie do dostarczania aplikacji w tej postaci. Wraz z wersją Tcl 8.1 powstało również pierwsze darmowe rozwiązanie do dostarczania aplikacji w Tcl/Tk jako samodzielny plik wykonywalny – freeWRAP.

Od wersji 8.4 część Tcl C API odpowiedzialna za dostęp do plików została zmieniona. Jedną z ważniejszych zmian jest możliwość rejestrowania wielu „dostawców” (providers) systemów plików – standardowym jest system plików oferowany przez system operacyjny, określany często mianem natywnego. Dzięki temu powstało kilka innych rozwiązań – m.in. Tclkit, który stworzył również system plików dedykowany dla języka Tcl/Tk oraz jego nieformalny następca Cookit, który dzięki zmianach w sposobie kompresji pozwala na generowanie znacznie mniejszych plików wynikowych.

 Dzięki temu, iż od ponad 10 lat język Tcl oferuje API do operacji na plikach, wiele rozszerzeń napisanych w czystym C nie ma kłopotów (tak długo jak używają funkcji plikowych z Tcl C API zamiast z języka C) z poprawnym dostępem do zasobów zarówno w natywnym, jak i w wirtualny systemie plików. Przykładem jest pakiet graficzny Tk, który pozwala przykładowo na odczyt obrazków wprost z archiwum lub pakiet Snack, oferujący możliwość odtwarzania muzyki wprost z wirtualnego systemu plików.

Wolumeny oraz dostawcy systemów plików

Tcl zakłada istnienie wielu wolumenów, czyli ścieżek pod jakimi dany system plików jest dostępny – na przykład są to C:\, D:\ i wszystkie inne dyski na systemach Windows oraz / dla systemów typu Unix. W tym drugim przypadku nie ma rozróżnienia pomiędzy urządzeniami fizycznymi zarejestrowanymi w systemie – np. nawet jeśli w katalogu /media/usbstick dostępny jest pendrive, Tcl nie traktuje go osobny wolumen.

Każdy dodatkowy system plików może zarejestrować się jako punkt montowania w istniejącym już wolumenie – np /tmp/myvfs lub jako nowy wolumen jak na przykład http:// czy ftp://.

Czysty język Tcl pozwala na tworzenie własnych systemów plików jedynie z poziomu C. W tym celu należy zaimplementować odpowiednie funkcje – takie jak pobieranie zawartości katalogu, informacji o poszczególnych plikach i katalogach oraz funkcje związane z otwieraniem plików do odczytu lub zapisu - oraz zarejestrować nowy system plików w środowisku Tcl.

Tworzenie systemów plików na poziomie skryptów Tcl

Nie każdy użytkownik Tcla jest jednocześnie znawcą języka C. Aby również i to grono programistów mogło w pełni korzystać z uroków VFSów, powstał pakiet tclvfs, który umożliwia implementację w oparciu o czyste skrypty Tcl, bez potrzeby kodowania natywnego i kompilacji. Analogicznie, również w tym przypadku wymagane jest zaimplementowanie pewnego zestawu funkcji (poleceń Tcla) związanych z pobieraniem informacji o katalogach i plikach. Polecenia te są odpowiednikami niskopoziomowych funkcji języka C takich jak access czy stat.

Pakiet tclvfs zawiera również kilka „gotowych” dostawców systemów plików – m.in. obsługę archiwów zip, tar, czy dostęp do plików poprzez http lub ftp. Są one nie tylko gotowymi do użycia implementacjami, ale również – dzięki dostępowi do kodu źródłowego - znakomitym źródłem wiedzy. Tclvfs dostarczany jest z najpopularniejszą dystrybucją języka Tcl – ActiveTcl firmy ActiveState.

Systemy plików a odczyt i zapis

Same systemy plików – zarówno te napisane w Tcl jak i w C – oferują przede wszystkim operacje (np. kopiowanie czy usuwanie) na plikach i katalogach. Architektura języka Tcl zakłada, że każda operacja wejścia/wyjścia wymaga skorzystania z kanałów, musimy o to zatroszczyć się również w przypadku odczytu lub zapisu do plików ulokowanych w naszym VFSie.

Tcl pozwala na tworzenie kanałów w C, w Tcl oraz nakładanie warstw (stacking). Pierwsze dwie opcje pozwalają na stworzenie nowego typu kanału. Przykładowo pakiet zipvfs implementuje własne kanały w celu czytania plików wprost z archiwum zip (bez czytania całości pliku do pamięci). Najczęstszym rozwiązaniem jest jednak skorzystanie z gotowego rozwiązania – memchan.

Tcl oferuje standardowe typy kanałów – np. odczyt i zapis do plików (natywny FS) oraz strumienie TCP/IP do komunikacji sieciowej.

Nakładanie warstw na kanały pozwala na rozszerzenie funkcjonalności istniejącego kanału – na przykład otwarcie pliku do odczytu i nałożenie warstwy odpowiedzialnej za kompresję czy szyfrowanie.

Czytanie lub zapis do pliku wymaga stworzenia kanału, który pozwala na wykonanie tych operacji oraz - opcjonalnie - polecenia, które zostanie wykonane po zamknięciu pliku (tzw. callback). Dzięki temu korzystając z istniejącego mechanizmu memchan można zaimplementować podstawowe operacje na plikach – przy otwarciu pliku jego poprzednia zawartość jest zapisywana do pamięci, po jego zamknięciu nowa zawartość jest zachowywana do pliku.

vfs::zip

Pierwszą implementacją VFS jaką omówimy jest pakiet vfs::zip będący częścią projektu tclvfs. Jak łatwo odgadnąć, pozwala on na dostęp do struktur plików zachowanych w archiwach zip. Aby praktycznie sprawdzić jego działanie, wystarczy stworzyć archiwum zip dowolnym narzędziem, musimy uruchomić konsolę Tcl (tclsh) i wpisać:

1
2

% package require vfs::zip
% vfs::zip::Mount /katalog/plik.zip /katalog/plik.zip

Pierwszy argument polecenia vfs::zip::Mount to ścieżka do archiwum, drugie to miejsce, w którym dane archiwum zostanie zarejestrowane. Pewnego rodzaju konwencją jest montowanie pliku archiwum pod taką samą nazwą – od tego momentu plik.zip będzie przypominał katalog.

Następnie możemy już pracować z zawartością archiwum tak jak ze wszystkimi innymi plikami. Dla przykładu, aby skopiować plik z archiwum wystarczy wpisać:

1

% file copy /katalog/plik.zip/image.gif /tmp/image.gif

Wszystkie funkcje języka Tcl poprawnie obsługują pliki korzystające z wirtualnych systemów plików – na przykład:

1

% image create photo –file /katalog/plik.zip/image.gif

Spowoduje to wczytanie obrazka wprost z archiwum.

Zipvfs pozwala również na wykonywanie praktycznie wszystkich operacji, które można wykonać na natywnych systemach plików:

1
2
3

foreach f [glob -directory plik.zip *] {
    puts "[format "%s %s %4s bytes" $f [file type $f] [file size $f]]"
}

 Wynikiem powyższego kodu może być na przykład:

1
2

plik.zip/readme.txt file 20 bytes
plik.zip/image.gif file 10234 bytes

 Po zakończeniu pracy warto odmontować dany udział poleceniem vfs::unmount . Konwencja ta dotyczy każdej implementacji VFS.

Pakiet vfs::zip pozwala na otwieranie zarówno klasycznych archiwów, jak i takich, w których skompresowana zawartość poprzedzone są innym ciągiem danych – jak na przykład pliki samorozpakowujące. Właściwość ta bywa wykorzystywana do tworzenia skryptów Tcl o zredukowanym rozmiarze: początek pliku to skrypt, który otwiera sam siebie jako archiwum zip oraz uruchamia właściwy kod.

Zipvfs oferuje jedynie funkcjonalność odczytu zawartości archiwum, nie pozwala natomiast na wykonywanie zmian na plikach. Oczywiście istnieją pakiety, pozwalające na tworzenie archiwów zip z poziomu Tcl w bezpośredni sposób (bez emulacji systemu plików).

vfs::http

Inną ciekawą implementacją VFS jest obsługa zasobów dostępnych za pomocą protokołu http. Pomimo istotnych ograniczeń w oferowanej przez nią funkcjonalności może znakomicie ułatwić obsługę komunikacji sieciowej, sprowadzając całą procedurę pobrania danego zasobu do zwykłego odczytu pliku. Jako przykładem posłużmy się następującym kodem:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23

proc head {filename count} {
    puts "\n==== $filename"
    set fp [open $filename r]
    fconfigure $fp -buffering line
 
    set i 0;
    while {$i < $count} {
        puts "> [gets $fp]"
    incr i
    }
    close $fp
}
 
package require vfs::http
vfs::http::Mount "http://www.kernel.org/pub/linux/kernel" kernel
puts "file type of mounted resource: [file type kernel]"
 
file copy -force kernel/README readme.txt
 
head readme.txt 7
head kernel/v2.6/ChangeLog-2.6.38.3 7
 
vfs::unmount kernel

Procedura head jest odpowiednikiem analogicznej komendy linuxowej, i ma za zadanie wypisać na ekran wyspecyfikowaną ilość linii z danego pliku.

Kod odpowiedzialny za komunikację http znajduje się w pakiecie vfs::http.

Komenda vfs::http::Mount "http://www.kernel.org/pub/linux/kernel" kernel powoduje utworzenie w bieżącym katalogu wirtualnego zasobu (punktu montowania) o nazwie kernel. Obecna implementacja pozwala na traktowanie tego zasobu jako read-only>. Przy okazji pokazaliśmy jedno z jej ograniczeń – pomimo że kernel będziemy traktować jak katalog, Tcl traktuje go jako zasób typu file. Następne komendy ilustrują brak różnic pomiędzy dostępem do plików lokalnych a dostępnych po http. Kopiujemy zdalny plik README na lokalny readme.txt, a następnie wypisujemy z niego pierwsze 7 linii. Następne polecenie zrobi to samo bezpośrednio na zdalnym pliku http://www.kernel.org/pub/linux/kernel/v2.6/ChangeLog-2.6.38.3, zaś ostatnia komenda odmontowuje udział kernel, zwalniając użyte zasoby sieciowe. Wynik działania powyższego kodu to:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17

file type of mounted resource: file
 
==== readme.txt
> 
>       Linux kernel release 2.0.xx
> 
> These are the release notes for linux version 2.0.  Read them carefully,
> as they tell you what this is all about, explain how to install the
> kernel, and what to do if something goes wrong.
 
==== kernel/v2.6/ChangeLog-2.6.38.3
> commit 1be99f6c95e6c887756f789a60d15771235acd0c
> Author: Greg Kroah-Hartman 
> Date:   Thu Apr 14 13:03:56 2011 -0700
> 
>     Linux 2.6.38.3
> 

Na powyższym przykładzie zalety VFSów uwypuklają się w całej okazałości. Pomimo że kod korzysta z protokołu http, nie musimy zajmować się zagadnieniami programowania sieciowego taki mi jak nawiązywanie połączenia, pobieranie zawartości czy obsługa timeoutów itp.

Warto podkreślić, że w przypadku pakietu vfs::http tylko niektóre funkcje zostały zaimplementowane: przykładowo próba wylistowania zawartości podmontowanego zasobu poleceniem glob -directory kernel nie zadziała. Pamiętajmy również że protokół http nie został zaprojektowany jako protokół zdalnego dostępu i zarządzania plikami, co nakłada dodatkowe ograniczenia.

vfs::ftp

Obsługa protokołu ftp przez sterownik VFS nie różni się znacznie od opisanego powyżej http. Poniżej kod z poprzedniego przykładu zmodyfikowany pod kątem użycia ftp (definicja komendy head pozostaje bez zmian):

1
2
3
4
5
6
7
8
9

package require vfs::ftp
vfs::ftp::Mount "ftp://ftp.kernel.org/pub/linux/kernel" kernel
puts "file type of mounted resource: [file type kernel]"
 
file copy -force kernel/README readme.txt
head readme.txt 7
head kernel/v2.6/ChangeLog-2.6.38.3 7
 
vfs::unmount kernel

vfs::urltype

Wspomnieliśmy wcześniej, że TclVFS oferuje 2 tryby dostępu do VFS – poprzez punkt montowania, lub wolumen. Pierwszy z nich poznaliśmy w poprzednich przykładach – polega on na udostępnieniu konkretnego, zdalnego udziału (zazwyczaj logicznego odpowiednika katalogu) jednoznacznie identyfikowanego przez podany adres, jako lokalny punkt montowania i wykonywanie na nim operacji.

Drugi tryb pozwala na zdefiniowanie wirtualnych napędów typu ftp:// i http://. W tym przypadku identyfikacja interesującego nas zasobu ma miejsce dopiero w chwili wykonywania na nim konkretnej operacji, co implikuje używanie bezwzględnych ścieżek (URL). Użycie pakietu vfs::urltype wygląda następująco:

1
2
3
4
5
6
7

package require vfs::urltype
vfs::urltype::Mount ftp
vfs::urltype::Mount http
head ftp://ftp.kernel.org/pub/linux/kernel/README 7
head http://www.kernel.org/pub/linux/kernel/README 7
 
puts [file volumes]

Mk4vfs

Podstawową zaletą pakietu jest pełna obsługa odczytu i zapisu. Dzięki korzystaniu z bazy danych Metakit, wszystkie zmiany w systemie plików są transakcyjne – co sprawia, że nawet w przypadku przerwania operacji zapisu plików, nie dochodzi do uszkodzenia archiwum.

Składnia jest bardzo podobna do operacji na archiwach zip. Jeśli chcemy otworzyć archiwum mk4 musimy wykonać następujące polecenia:

1
2

package require vfs::mk4
vfs::mk4::Mount /katalog/plik.mk4 /katalog/plik.mk4

Pierwszy argument to ścieżka do archiwum, drugi to punkt montowania. W przypadku gdy plik nie istnieje, jest on automatycznie tworzony. Standardowo archiwum otwierane jest w trybie do odczytu i zapisu.
Jeśli chcemy otworzyć archiwum w trybie tylko do odczytu, musimy dodać opcję -readonly:

1

vfs::mk4::Mount /katalog/plik.mk4 /katalog/plik.mk4 -readonly

Wszelkie operacje wykonywane są tak samo jak w przypadku archiwów zip. Natomiast w przypadku archiwów otwartych do odczytu i zapisu możliwe jest też tworzenie plików w archiwum – na przykład:

1

file copy /tmp/image.gif /katalog/plik.mk4/image.gif

Ponieważ w przeciwieństwie do wcześniej opisanych VFSów mamy tutaj obsługę zapisu, istotne jest „czyste" zamknięcie danego pliku poprzez jego odmontowanie:

1

vfs::unmount plik.mk4

Cookfs

Kolejnym formatem stworzonym głównie z myślą o języku Tcl/Tk jest cookfs. Jest to format, który podobnie do mk4vfs powstał na potrzeby tworzenia jednoplikowych programów zawierających Tcl oraz skrypty. Cookfs rozwiązuje problemy, które można spotkać przy pracy zarówno z formatem zip oraz mk4 – pozwala na zapisywanie do archiwów oraz nie wymaga bibliotek C++ (co niejednokrotnie bywa problemem w przypadku starszych systemów operacyjnych). Dodatkowo cookfs jest zoptymalizowany pod kątem dużej ilości małych plików – podobnie jak formaty rar lub 7z, małe pliki pakowane są wspólnie, przez co wynikowy rozmiar pliku jest mniejszy. Cookfs zostanie szczegółowo opisany w następnym artykule.
W przeciwieństwie do wyżej opisanych VFSów, cookfs nie jest częścią tclvfs i należy go doinstalować. Proces ten nie jest szczególnie skomplikowany i sprowadza się do pobrania ze strony http://sourceforge.net/projects/cookit/ providera skompilowanego pod daną platformę (cookfs jest napisany zarówno w Tcl jak i w C) i umieszczeniu go w katalogu wskazywanym przez zmienną $auto_path interpretera (zazwyczaj jest to podkatalog lib).
Użytkowanie archiwum cookfs nie odbiega od składni mk4vfs i ilustruje je kod poniżej. W skrypcie tym kolejno:

1. załadowaliśmy pakiet vfs::cookfs
2. utworzyliśmy archiwum plik.cfs podmontowane pod tą samą nazwą
3. utworzyliśmy plik readme.txt wewnątrz archiwum
4. używając wcześniej opisanej procedury head wypisaliśmy zawartość pliku
5. odmontowaliśmy archiwum

1
2
3
4
5
6
7

package require vfs::cookfs
vfs::cookfs::Mount plik.cfs plik.cfs
set channel [open plik.cfs/readme.txt w]
puts $channel "Hello from Cookfs!"
close $channel
head plik.cfs/readme.txt 1  
vfs::unmount plik.cfs

 Wynik działania skryptu jest następujący:

1
2

==== ./plik.cfs/readme.txt
 Hello from Cookfs!

Podsumowanie

• http://sourceforge.net/projects/tclvfs/
• http://memchan.sourceforge.net/
• http://docs.activestate.com/activetcl/8.5/tcl/TclLib/FileSystem.htm
• http://docs.activestate.com/activetcl/8.5/tclvfs/doc/vfs.html
• http://sourceforge.net/projects/cookit
• http://equi4.com/metakit/

Piotr Bełtowski

Wojciech Kocjan