17Aug
Podczas korzystania z systemu Linux i OS X system operacyjny nie powstrzyma cię przed usunięciem aktualnie używanego pliku w systemie Windows, co spowoduje, że nie będziesz mieć do niego dostępu. Co daje? Dlaczego można edytować i usuwać pliki w użyciu w systemach pochodnych Unix, ale nie w systemie Windows?
Dzisiejsze pytanie &Sesja odpowiedzi przychodzi do nas dzięki uprzejmości SuperUser - poddziału Stack Exchange, opartego na społecznościach grupy Q & A.
Pytanie Czytnik
SuperUser the.midget chce wiedzieć, dlaczego Linux i Windows traktują pliki w użyciu w różny sposób:
Jedną z rzeczy, która mnie zastanawiała od kiedy zacząłem używać Linuksa, jest fakt, że pozwala to na zmianę nazwyplik lub nawet usunąć go podczas odczytu. Przykładem jest sposób, w jaki przypadkowo próbowałam usunąć wideo podczas odtwarzania. Udało mi się i byłem zaskoczony, gdy dowiedziałem się, że możesz zmienić prawie wszystko w pliku, nie dbając o to, czy jest on aktualnie używany, czy nie.
A więc co dzieje się za kulisami i nie pozwala mu bezmyślnie usuwać rzeczy w systemie Windows, tak jak on w Linuksie?
Odpowiedzi
SuperUser rzucają nieco światła na sytuację dla.midget. Zdziwiony pisze:
Za każdym razem, gdy otwierasz lub uruchamiasz plik w systemie Windows, system Windows blokuje plik w miejscu( jest to uproszczenie, ale zazwyczaj prawdziwe). Plik zablokowany przez proces nie może zostać usunięty, dopóki ten proces go nie zwolni. Dlatego zawsze, gdy Windows musi się aktualizować, konieczne jest ponowne uruchomienie systemu, aby mógł on działać.
Z drugiej strony, systemy operacyjne podobne do Uniksa, takie jak Linux i Mac OS X, nie blokują pliku, a raczej leżące u jego podstaw sektory dyskowe. Może to wydawać się trywialnym rozróżnieniem, ale oznacza to, że rekord pliku w spisie treści systemu plików można usunąć bez zakłócania działania żadnego programu, który już ma otwarty plik. Możesz więc usunąć plik, gdy nadal jest on wykonywany lub w inny sposób używany, i będzie istnieć na dysku, dopóki jakiś proces ma otwarty uchwyt do niego, nawet jeśli jego wpis w tabeli plików zniknął.
David Schwartz rozwija ideę i podkreśla, w jaki sposób rzeczy powinny być idealnie i jak są w praktyce:
Windows domyślnie zamyka automatyczne blokowanie plików. Domyślnie UNIXy to ręczne, wspólne blokowanie plików. W obu przypadkach wartości domyślne można przesłonić, ale w obu przypadkach zwykle nie.
Wiele starych kodów systemu Windows używa C / C ++ API( funkcje takie jak fopen) zamiast natywnego API( funkcje takie jak CreateFile).Interfejs API C / C ++ nie pozwala określić, jak będzie działać blokowanie obowiązkowe, więc otrzymasz ustawienia domyślne. Domyślny "tryb udostępniania" ma tendencję do blokowania "sprzecznych" operacji. Jeśli otworzysz plik do zapisu, zakłada się, że zapisy powodują konflikt, nawet jeśli nigdy nie piszesz do pliku. Podobnie jak w przypadku nazw.
I tu jest coraz gorzej. Oprócz otwierania do odczytu lub zapisu, C / C ++ API nie daje możliwości określenia, co zamierzasz zrobić z tym plikiem. A więc API musi zakładać, że wykonasz jakąkolwiek operację prawną.Ponieważ blokowanie jest obowiązkowe, odmowa otwarcia, która pozwala na konfliktową operację, zostanie odrzucona, nawet jeśli kod nigdy nie miał na celu wykonania operacji powodującej konflikt, ale właśnie otwierał plik w innym celu.
Jeśli więc kod używa interfejsu API C / C ++ lub używa natywnego API bez szczególnego myślenia o tych problemach, zostaną one zakończone, zapobiegając maksymalnemu zestawowi możliwych operacji dla każdego otwieranego pliku i niemożności otwarcia pliku, chyba że każda możliwa operacjamogli wykonać na nim po otwarciu nie są zagrożeni.
Moim zdaniem, metoda Windowsa działałaby znacznie lepiej niż metoda UNIX, gdyby każdy program wybrał tryby udostępniania i mądrze otworzył tryby, a sowicie obsłużył awarie. Metoda UNIX działa jednak lepiej, jeśli kod nie zastanawia się nad tymi problemami. Niestety podstawowy interfejs API C / C ++ nie jest dobrze mapowany na interfejs API pliku systemu Windows w sposób, który obsługuje dobrze tryby udostępniania i sprzeczne otwarcia. Więc wynik netto jest trochę brudny.
Masz to: dwa różne podejścia do obsługi plików dają dwa różne wyniki.
Czy chcesz coś dodać do wyjaśnienia? Dźwięk w komentarzach. Chcesz przeczytać więcej odpowiedzi od innych użytkowników Stack Exchange, którzy znają się na technologii? Sprawdź cały wątek dyskusji tutaj.
