Blokowanie plików wykonywalnych: Windows tak, Linux nie. Czemu?

Zauważyłem, że gdy plik jest wykonywany w systemie Windows (.exe lub .dll), jest on zablokowany i nie można go usunąć, przenieść ani zmodyfikować.

Z drugiej strony Linux nie blokuje plików wykonywalnych i można je usuwać, przenosić lub modyfikować.

Dlaczego system Windows blokuje się, a Linux nie? Czy blokowanie ma zalety?

Linux ma mechanizm zliczania odwołań, więc możesz usunąć plik podczas jego wykonywania i będzie on istniał tak długo, jak długo jakiś proces (który wcześniej go otworzył) ma dla niego otwarty uchwyt. Wpis katalogu dla pliku jest usuwany po jego usunięciu, więc nie można go już otworzyć, ale procesy, które już używają tego pliku, mogą go nadal używać. Po zakończeniu wszystkich procesów korzystających z tego pliku plik jest automatycznie usuwany.

System Windows nie ma takiej możliwości, więc jest zmuszony do zablokowania pliku do czasu zakończenia wszystkich wykonywanych z niego procesów.

Uważam, że zachowanie Linuksa jest lepsze. Prawdopodobnie istnieje kilka głębokich powodów architektonicznych, ale głównym (i prostym) powodem, dla którego uważam go za najbardziej przekonujący, jest to, że w systemie Windows czasami nie można usunąć pliku, nie masz pojęcia dlaczego, a wszystko, co wiesz, to to, że jakiś proces utrzymuje go w posługiwać się. W Linuksie to się nigdy nie zdarza.

O ile mi wiadomo, Linux czy wykonywalne blokady, gdy są one uruchomione - jednak blokuje iwęzeł . Oznacza to, że możesz usunąć „plik”, ale i-węzeł nadal znajduje się w systemie plików, nietknięty, a wszystko, co naprawdę usunąłeś, to łącze.

Programy uniksowe cały czas używają tego sposobu myślenia o systemie plików, tworzą plik tymczasowy, otwierają go, usuwają nazwę. Twój plik nadal istnieje, ale jego nazwa jest dostępna dla innych i nikt inny nie może go zobaczyć.

Linux blokuje pliki. Jeśli spróbujesz nadpisać plik, który jest wykonywany, otrzymasz „ETXTBUSY” (plik tekstowy zajęty). Możesz jednak usunąć plik, a jądro usunie plik po usunięciu ostatniego odniesienia do niego. (Jeśli komputer nie został prawidłowo zamknięty, te pliki są przyczyną komunikatu „Usunięty i-węzeł miał zerowy czas d” podczas sprawdzania systemu plików, nie zostały one całkowicie usunięte, ponieważ działający proces miał do nich odniesienie, a teraz są).

Ma to kilka głównych zalet, możesz zaktualizować uruchomiony proces, usuwając plik wykonywalny, zastępując go, a następnie ponownie uruchamiając proces. Nawet init może zostać zaktualizowany w ten sposób, podmienić plik wykonywalny i wysłać mu sygnał, a sam zrestartuje exec () bez konieczności ponownego uruchamiania. (Zwykle jest to wykonywane automatycznie przez system zarządzania pakietami w ramach jego aktualizacji)

W systemie Windows zastąpienie używanego pliku wydaje się być dużym problemem, zazwyczaj wymagającym ponownego uruchomienia, aby upewnić się, że nie są uruchomione żadne procesy.

Mogą wystąpić pewne problemy, na przykład jeśli masz bardzo duży plik dziennika i usuniesz go, ale zapomnisz powiedzieć procesowi, który logował się do tego pliku, aby ponownie otworzył plik, będzie przechowywać odniesienie i będziesz się zastanawiać dlaczego na dysku nagle nie było dużo więcej wolnego miejsca.

Możesz również użyć tej sztuczki pod Linuksem dla plików tymczasowych. otwórz plik, usuń go, a następnie kontynuuj korzystanie z pliku. Po zakończeniu procesu (bez względu na przyczynę - nawet awaria zasilania), plik zostanie usunięty.

Programy takie jak lsof i fuser (lub po prostu szperające w / proc // fd) mogą pokazać, które procesy mają otwarte pliki, które nie mają już nazwy.

Myślę, że linux / unix nie używa tej samej mechaniki blokowania, ponieważ są zbudowane od podstaw jako system dla wielu użytkowników - co wymagałoby możliwości używania tego samego pliku przez wielu użytkowników, być może nawet do różnych celów.

Czy blokowanie ma zalety? Cóż, prawdopodobnie mogłoby to zmniejszyć liczbę wskaźników, którymi system operacyjny musiałby zarządzać, ale teraz kwota oszczędności jest znikoma. Największą zaletą blokowania, o której mogę pomyśleć, jest to: oszczędzasz pewną niejednoznaczność widoczną dla użytkownika. Jeśli użytkownik a uruchamia plik binarny, a użytkownik b go usuwa, wówczas rzeczywisty plik musi pozostać, dopóki proces użytkownika A nie zostanie zakończony. Jeśli jednak użytkownik B lub jakikolwiek inny użytkownik będzie szukał go w systemie plików, nie będzie w stanie go znaleźć - ale będzie on nadal zajmował miejsce. Nie jest to dla mnie wielkim problemem.

Myślę, że w dużej mierze jest to kwestia kompatybilności wstecznej z systemami plików Windows.

Myślę, że jesteś zbyt zdecydowany co do Windows. Zwykle nie przydziela miejsca wymiany dla części kodu pliku wykonywalnego. Zamiast tego blokuje pliki wykonywalne & DLL. Jeśli ponownie będą potrzebne odrzucone strony kodowe, po prostu zostaną ponownie załadowane. Ale z / SWAPRUN te strony są zachowywane w zamian. Służy do plików wykonywalnych na dyskach CD lub dyskach sieciowych. Dlatego system Windows nie musi blokować tych plików.

W przypadku platformy .NET spójrz na Shadow Copy .

Decyzja o tym, czy wykonywany kod w pliku ma być zablokowany, czy nie, jest decyzją projektową, a MS po prostu zdecydowało się na blokadę, ponieważ ma to wyraźne zalety w praktyce: w ten sposób nie musisz wiedzieć, który kod, w jakiej wersji jest używany przez którą aplikację. Jest to poważny problem z domyślnym zachowaniem Linuksa, które jest po prostu ignorowane przez większość ludzi. Jeśli zastąpione zostaną biblioteki systemowe, nie będzie łatwo wiedzieć, które aplikacje używają kodu takich bibliotek. W większości przypadków najlepsze, co można uzyskać, to znajomość przez menedżera pakietów niektórych użytkowników tych bibliotek i ponowne ich uruchomienie. Ale to działa tylko w przypadku ogólnych i dobrze znanych rzeczy, takich jak może Postgres i jego biblioteki lub takie. Bardziej interesujące scenariusze dotyczą sytuacji, gdy tworzysz własną aplikację dla niektórych bibliotek innych firm, a te są zastępowane, ponieważ w większości przypadków menedżer pakietów po prostu nie zna Twojej aplikacji. I to' jest to nie tylko problem z natywnym kodem C lub tym podobnym, może się zdarzyć prawie ze wszystkim: po prostu użyj httpd z mod_perl i niektórymi bibliotekami Perla zainstalowanymi za pomocą menedżera pakietów i pozwól menedżerowi pakietów zaktualizować te biblioteki Perl z dowolnego powodu. Nie zrestartuje twojego httpd, po prostu dlatego, że nie zna zależności. Istnieje wiele przykładów takich jak ten, po prostu dlatego, że każdy plik może potencjalnie zawierać kod używany w pamięci przez dowolne środowisko uruchomieniowe, pomyśl o Javie, Pythonie i innych podobnych rzeczach.

Jest więc dobry powód, by sądzić, że domyślne blokowanie plików może być dobrym wyborem. Nie musisz jednak zgadzać się z tymi powodami.

Więc co zrobił SM? Po prostu stworzyli API, które daje aplikacji wywołującej szansę na podjęcie decyzji, czy pliki powinny być blokowane, czy nie, ale zdecydowali, że domyślną wartością tego API jest zapewnienie wyłącznej blokady dla pierwszej aplikacji wywołującej. Spójrz na interfejs API w okolicy CreateFile i jego dwShareModeargument. To jest powód, dla którego możesz nie być w stanie usunąć plików używanych przez jakąś aplikację, po prostu nie dba o Twój przypadek użycia, używał wartości domyślnych i dlatego ma wyłączną blokadę pliku przez system Windows.

Proszę nie wierz w to, że ludzie mówią ci coś o systemie Windows, który nie korzysta z liczenia referencji na UCHWYTACH lub nie obsługuje Hardlinks lub podobnych, to jest całkowicie błędne. Prawie każde API używające HANDLEs dokumentuje swoje zachowanie dotyczące liczenia referencji i możesz łatwo przeczytać w prawie każdym artykule na temat NTFS, który faktycznie obsługuje Hardlinks i zawsze to robił. Od systemu Windows Vista obsługuje również łącza symboliczne, a obsługa łączy twardych została ulepszona poprzez udostępnienie interfejsów API do odczytu wszystkich tych dla danego pliku itp.

Dodatkowo możesz po prostu rzucić okiem na struktury używane do opisu pliku np. W Ext4 w porównaniu do tych w NTFS , które mają wiele wspólnego. Oba działają z koncepcją zakresów, która oddziela dane od atrybutów, takich jak nazwa pliku, a i-węzły to po prostu inna nazwa dla starszej, ale podobnej koncepcji. Nawet Wikipedia wymienia oba systemy plików w swoim artykule .

Jest naprawdę dużo FUD wokół blokowania plików w systemie Windows w porównaniu z innymi systemami operacyjnymi w sieci, podobnie jak w przypadku defragmentacji. Niektóre z tych FUD można wykluczyć, po prostu czytając trochę w Wikipedii .

Warianty NT mają

Otwórz pliki

polecenie, które pokaże, które procesy mają uchwyty do których plików. Wymaga to jednak włączenia globalnej flagi systemu „zachowaj listę obiektów”

openfiles / local /?

mówi, jak to zrobić, a także, że powoduje to spadek wydajności.

Pliki wykonywalne są stopniowo mapowane do pamięci podczas uruchamiania. Oznacza to, że części pliku wykonywalnego są ładowane w razie potrzeby. Jeśli plik zostanie wymieniony przed mapowaniem wszystkich sekcji, może to spowodować poważną niestabilność.