CreateFile FILE_FLAG_DELETE_ON_CLOSE kończy się niepowodzeniem po zamknięciu dowolnego uchwytu.

Tworzymy plik do użycia jako plik memorymapped.CreateFile FILE_FLAG_DELETE_ON_CLOSE kończy się niepowodzeniem po zamknięciu dowolnego uchwytu.

otwieramy z GENERIC_READ | GENERIC_WRITE
używamy udział z FILE_SHARE_READ | FILE_SHARE_WRITE | FILE_SHARE_DELETE
używamy atrybutów pliku FILE_ATTRIBUTE_TEMPORARY | FILE_FLAG_DELETE_ON_CLOSE

tworzymy plik pomyślnie. Możemy go otworzyć ponownie wiele razy z tymi samymi flagami, które chcemy.

Po zamknięciu jednego uchwytu nie możemy już otwierać żadnych uchwytów, a funkcja zwraca ERROR_ACCESS_DENIED. Możemy spowodować to przez zamknięcie dowolnego z uchwytów, albo pierwszego z CreateFile (ALWAYS_CREATE), albo innych z CreateFile (OPEN_EXISTING).

Czy można tego uniknąć? Używamy memoryMappedFile jako komunikacji między różnymi procesami, które muszą współdzielić zasoby. te procesy czasami zaczynają się i kończą. Właśnie teraz, gdy zamykamy jeden uchwyt, utknęliśmy w stanie, aby otworzyć plik memorymapped.

Próbowałem zmienić otwarte połączenia, aby używać funkcji FILE_ATTRIBUTE_NORMAL, więc tylko wywołanie create używa CLOSE_ON_DELETE, ale to nie ma wpływu na tę sytuację.

Źródło

2015-04-13 cdturner

twoje procesy powinny koordynować i tylko "master" powinien używać flagi delete_on_close, master jest pierwszym, który uruchamia się, a ostatni zamyka. –

Skupiasz się na niewłaściwym problemie. Tak, bardzo trudno jest poradzić sobie z procesem, który nieoczekiwanie ginie w tego rodzaju scenariuszu. Wiele innych rzeczy jest nie tak poza plikiem, który nie zostaje usunięty, a impas jest tradycyjny. Często potrzebujesz procesu ochronnego, który nie robi nic innego, ale zapewnia, że wszyscy współpracują i czyści, gdy tego nie robią. Ten plik, który nie zostanie usunięty, jest najmniejszym problemem, dostaniesz go następnym razem. –

Problem polega na tym, że po otwarciu uchwytu pliku z zamkniętym FILE_FLAG_DELETE_ON_CLOSE system operacyjny nie będzie już pozwalał na tworzenie nowych uchwytów.

Szczegóły: Podczas przetwarzania IRP_MJ_CLEANUP (co się dzieje, wygraj klamkę jest zamknięta) dla pliku otwartego do usunięcia przy zamknięciu, systemy plików Windows ustawią wewnętrzną flagę na obiekcie pliku wskazując, że jest on włączony to wyjście. Kolejne otwarte próby na pliku nie powiodą się z STATUS_DELETE_PENDING, którą podsystem Win32 będzie mapował do kodu Win32 ERROR_ACCESS_DENIED, który widzisz.

Dla swojego przypadku użycia, możesz rozważyć użycie wzoru Named Shared Memory (MSDN). Zasadniczo pozwól systemowi operacyjnemu zarządzać przestrzenią pamięci współdzielonej. Po prostu upewnij się, że zastosowałeś odpowiednie atrybuty bezpieczeństwa i jesteś gotowy.

Źródło

2015-04-13 22:04:46 Bukes

Dziękuję za jasność. Wyobrażałem sobie tyle z tego, co zauważyłem ze strony trybu użytkownika. Próba usunięcia flagi przy zamknięciu była ostatnim dodatkiem do obejścia przez użytkowników konieczności dodawania obsługi do ich skryptów. To było dla rzadkiego przypadku, gdy coś się zawiesza i nie jest prawidłowo oczyszczane. Zajmę się wykorzystaniem pliku stronicowania jako alternatywnego magazynu kopii zapasowych dla sekcji mapowanych w pamięci. Gory szczegóły bardzo doceniane i zrozumiałe. – cdturner

CreateFile FILE_FLAG_DELETE_ON_CLOSE kończy się niepowodzeniem po zamknięciu dowolnego uchwytu.

Odpowiedz

Powiązane problemy