Dlaczego nie mogę zmienić nazwy pliku odczytywanego w systemie Windows, tak jak mogę to zrobić w systemie Linux / Mac?

Jedną z rzeczy, które mnie intrygowały, odkąd zacząłem używać Linuksa, jest fakt, że pozwala on zmienić nazwę pliku, a nawet usunąć go podczas odczytu. Przykładem jest przypadkowa próba usunięcia filmu podczas jego odtwarzania. Udało mi się i byłem zaskoczony, gdy dowiedziałem się, że możesz zmienić prawie wszystko w pliku bez względu na to, czy jest on używany w tej chwili, czy nie.

Za każdym razem, gdy otwierasz lub uruchamiasz plik w systemie Windows, system Windows blokuje plik na miejscu (jest to uproszczenie, ale zwykle jest to prawda). Pliku zablokowanego przez proces nie można usunąć, dopóki ten proces go nie zwolni. Dlatego za każdym razem, gdy system Windows musi się zaktualizować, konieczne jest ponowne uruchomienie komputera, aby zadziałało.

Z drugiej strony, systemy operacyjne uniksopodobne, takie jak Linux i Mac OS X, nie blokują pliku, a raczej bazowe sektory dysku. Może się to wydawać trywialnym różnicowaniem, ale oznacza, że ​​rekord pliku w spisie treści systemu plików można usunąć bez zakłócania działania jakiegokolwiek programu, który już ma otwarty plik. Możesz więc usunąć plik, gdy jest on w trakcie wykonywania lub w inny sposób używany i będzie istniał na dysku, dopóki jakiś proces ma do niego otwarty uchwyt, nawet jeśli jego wpis w tabeli plików zniknął.

Domyślnym systemem Windows jest automatyczne, obowiązkowe blokowanie plików. W systemie UNIX domyślnie występuje ręczne, kooperatywne blokowanie plików. W obu przypadkach wartości domyślne mogą zostać zastąpione, ale w obu przypadkach zwykle nie są.

Wiele starych kodów Windows używa API C / C ++ (funkcje jak fopen) zamiast natywnego API (funkcje jak CreateFile). Interfejs API C / C ++ nie pozwala określić sposobu działania obowiązkowego blokowania, więc otrzymujesz wartości domyślne. Domyślny „tryb udostępniania” zabrania „sprzecznych” operacji. Jeśli otworzysz plik do zapisu, zakłada się, że zapisy powodują konflikt, nawet jeśli tak naprawdę nigdy nie zapisujesz do pliku. To samo dotyczy nazw.

I tutaj jest coraz gorzej. Poza otwieraniem do odczytu lub zapisu, interfejs API C / C ++ nie pozwala określić, co zamierzasz zrobić z plikiem. Dlatego interfejs API musi zakładać, że wykonasz dowolną operację prawną. Ponieważ blokowanie jest obowiązkowe, polecenie, openktóre pozwala na działanie w konflikcie, zostanie odrzucone, nawet jeśli kod nigdy nie zamierzał wykonać konfliktu, ale po prostu otwierał plik w innym celu.

Jeśli więc kod korzysta z interfejsu API C / C ++ lub korzysta z natywnego interfejsu API bez konkretnego myślenia o tych problemach, zostaną one zamknięte, uniemożliwiając maksymalny zestaw możliwych operacji dla każdego otwieranego pliku i niemożność otwarcia pliku, chyba że każda możliwa operacja może działać na nim, gdy otwarty jest nie jest sprzeczny.

Moim zdaniem metoda Windows działałaby znacznie lepiej niż metoda UNIX, gdyby każdy program wybrał tryby udostępniania i tryby otwarte mądrze i rozsądnie obsługiwał przypadki awarii. Metoda UNIX działa jednak lepiej, jeśli kod nie zawraca sobie głowy tymi problemami. Niestety, podstawowy interfejs API C / C ++ nie jest dobrze mapowany na interfejs API plików systemu Windows w sposób, który obsługuje tryby udostępniania, a konflikt otwiera się dobrze. Wynik netto jest więc nieco niechlujny.

To bardzo interesujące pytanie, które skłoniło mnie do zastanowienia się nad realną odpowiedzią. Mam nadzieję, że inni mogą zapewnić tutaj kopię zapasową.

Korzystam zarówno z systemu Windows, jak i Linux, i również to zauważyłem. Jestem także użytkownikiem vim. Vim wczyta plik tekstowy do „bufora” lub pamięci RAM, a następnie nie dotknie rzeczywistego pliku, dopóki go nie zapiszesz. Linux może wykonywać takie działania w ogóle ze wszystkimi plikami.

Weźmy na przykład film, odczytuje on film, jeśli to możliwe, do pamięci RAM, a następnie masz kopię wideo, która jest łatwo dostępna, możliwa do wyświetlenia, możliwa do przejścia. Jeśli plik jest zbyt duży, możesz napotkać problemy, ponieważ Linux może nie odczytać całego wideo, a może po prostu dużej części. Gdy odtwarzacz dotrze do końca buforowanego wideo, spróbuje ponownie odczytać plik. Jeśli usunąłeś film, to jest do bani.

Windows jest w niektórych przypadkach znacznie „bezpieczniejszym” systemem operacyjnym, ponieważ nie pozwala na to. Może buforować pliki w taki sam sposób jak Linux, ale dodaje także blokowanie plików, aby uniemożliwić Tobie lub innym programom zmianę plików, nad którymi pracujesz lub które przeglądasz. Pomaga to utrzymać plik w nienaruszonym stanie i chroni Ciebie lub inne programy przed wzajemnym nadpisywaniem zmian.