Podsumowując, mechanizm transakcyjny systemu Longhorn będzie mógł działać praktycznie na dowolnej warstwie - od sekwencji wysokopoziomowych instrukcji MSIL, poprzez operacje dyskowe, aż po warstwę komunikacyjną. Dzięki rozproszonym transakcjom twórca aplikacji nie będzie musiał martwić się o synchronizację danych w ramach aplikacji, tym zajmie się bowiem podsystem Indigo.

Plik, rzecz umowna

Transakcje obejmą każdą operację na wolumenie NTFS. W pełni obsługiwane będą cechy ACID (Atomicity, Consistency, Isolation, Durability). Operacja dyskowa (zapis, odczyt, utworzenie nowego pliku czy skasowanie) jest w Longhornie operacją atomową - albo zakończy się sukcesem, albo zostanie wycofana i system będzie przywrócony do poprzedniego stanu. Transakcyjność systemu plików w Longhornie obejmuje nie tylko dyski NTFS, ale także np. dyski sieciowe podłączone za pośrednictwem protokołu SMB. Oprócz operacji dyskowych mechanizmy transakcyjne obejmą tzw. pliki mapowane w pamięci.

To bardzo wygodny sposób dostępu do dużych plików, dzięki któremu zamiast operacji I/O program może manipulować blokiem pamięci operacyjnej. W każdej z tych sytuacji jest zapewniana odpowiednia izolacja pomiędzy różnymi transakcjami. Niestety, blokady są nakładane na poziomie całego pliku. Odczyt natomiast może się odbywać bez jakichkolwiek blokad.

Transakcje na NTFS działają w dwóch trybach. W tzw. trybie uproszczonym jest zapisywany stan pliku przed operacją, np. obcięciem czy nadpisaniem. Taka operacja jest mniej kosztowna niż "pełne" logowanie transakcji obejmujące (jak w bazie danych) całą historię operacji. Transakcyjność będzie można zdefiniować różnie dla różnych gałęzi katalogów - w jednych wystarczy tryb uproszczony, w innych zaś będzie potrzebna pełna szczegółowość. Gałąź drzewa katalogów zachowa raz ustalone właściwości transakcyjne, mimo przeniesienia w inne miejsce wolumenu.

Ponadto w systemie plików będzie można zdefiniować specjalny pojemnik (minibazę danych) wykorzystujący usługę Windows Logging Service. Mechanizm ten może w wielu przypadkach zastąpić np. pliki przechowujące stan aplikacji. System operacyjny zapewni trwałość zapisu i wysoką wydajność operacji dostępu do takiego pojemnika.

Na NTFS jest zbudowany WinFS - "widoczny" dla użytkownika, właściwy system plików systemu Longhorn. WinFS to zupełnie inne spojrzenie na organizację plików niż to, z czym mieliśmy do czynienia dotychczas. W WinFS pliki nie przynależą "sztywno" do katalogów, lecz mają pewne atrybuty określające ich cechy, wg których mogą być grupowane. Te same pliki mogą więc równocześnie należeć do wielu katalogów, w zależności od tego, jakie atrybuty zostały im przyznane. Przykładowo, dokument zawierający niniejszy artykuł może mieć atrybuty: dokument tekstowy, praca, Longhorn itd. Pliki mogą być łączone (grupowane) wg wartości atrybutu albo przez tworzenie bezpośrednich powiązań.

WinFS wprowadza innowacyjne podejście do plików. Plik widoczny dla użytkownika może tak naprawdę składać się z wielu plików, np. dokument może zawierać tekst i oddzielnie umieszczone rysunki. Z punktu widzenia aplikacji będzie to jeden plik, na poziomie NTFS zaś - wiele plików. Nic zatem dziwnego, że API WinFS bardziej przypomina API bazy relacyjnej niż niskopoziomowy dostęp do plików. Zresztą jedną z metod wyszukiwania plików jest... zadanie zapytania SQL. Pomimo tych udogodnień, programista może wybrać metodę pracy z danymi i np. ograniczyć się do API Win32.

W kaftanie bezpieczeństwa

W Longhornie będzie można określać poziom zaufania do źródła kodu. Przykładowo, kod pobrany przez administratora z obcej witryny będzie traktowany przez system jako mniej zaufany niż kod pobrany z domeny itd. Wynikowe uprawnienia będą powstawać z połączenia praw użytkownika i źródła kodu. Dodatkowo, np. biblioteki przed wykonaniem operacji muszą zażądać zwiększenia uprawnień - podobny mechanizm jest już dostępny w .Net.

Programiści zyskają w Longhornie łatwość definiowania tzw. zestawów wymaganych uprawnień. Co prawda w nowej wersji .Net atrybuty określające wymagany poziom uprawnień mają być bardziej rozbudowane, ale prawdopodobnie w Visual Studio Whidbey czy w .Net pojawią się mechanizmy pozwalające automatycznie wykryć minimalny zakres uprawnień dla aplikacji. Interfejsy API do obsługi bezpieczeństwa zostaną w systemie Longhorn zmienione tak, aby ułatwić wykonywanie typowych operacji. Uproszczona zostanie obsługa certyfikatów. Wszystkie te zabiegi mają na celu stworzenie klasy aplikacji typu Limited User - takich, które mogą prawidłowo działać z ograniczonymi uprawnieniami. Dotychczas łatwiej było wymagać pełnych uprawnień administracyjnych, niż zastanawiać się, jakie są naprawdę niezbędne.

Bezpieczeństwo aplikacji w systemie Longhorn ma dodatkowo podnieść bezpieczne środowisko SEE (Secure Execution Environment). Działające w nim aplikacje nie będą mogły uszkodzić systemu ani zakłócać pracy innych aplikacji. Takie funkcje mają być dostępne wyłącznie na platformie Longhorn. Microsoft deklaruje jednak, że spora część WinFX - w tym ok. 80% Indigo - będzie działać na Windows XP i 2003.