1

Topic: \ A file in a cycle

All greetings, Came across in network open spaces here such notice: https://boostgsoc13.github.io/boost.afi … iles.html. In particular, interested the following moment:... when the very last open handle to the file in the system is closed, only then is it truly deleted. Well, actually only sort of truly deleted, because Windows only appears to remove the file entry from the directory, but in fact that entry is merely hidden and actually still exists and attempting to create a file with the same name will return an access denied error. How long it silently exists for depends on a range of factors, but put it this way: if your code loops creating and deleting the same file name as you might when operating a lock file, you're going to see lots of random spurious access denied errors. I tried to achieve it such simply, but broke nothing (Win7): for (int i=0; i <10000; ++ i) {HANDLE file = CreateFileA ("test.file", GENERIC_WRITE, FILE_SHARE_DELETE, NULL, CREATE_NEW, 0, INVALID_HANDLE_VALUE); if (file == INVALID_HANDLE_VALUE) {std:: cout <<"c" <<i <<"" <<GetLastError () <<std:: endl;} else {if (0 == DeleteFileA ("test.file")) {std:: cout <<"d" <<i <<"" <<GetLastError () <<std:: endl;} CloseHandle (file);}} whether it Means, what article became outdated, or I misunderstood, what there is written also this situation it is possible to play back somehow in another way?

2

Re: \ A file in a cycle

Hello, tdiff, you wrote: T> <... Whether> T> it Means, what article became outdated, or I misunderstood, what there is written also this situation it is possible to play back somehow in another way? Article describes other situation: if on a remote file all descriptors are not closed (opened before removal) on its place it is impossible it is impossible to create the file with the same name. There was here an Author: Tolyan Date: 14.03.16.

3

Re: \ A file in a cycle

T>... when the very last open handle to the file in the system is closed, only then is it truly deleted. Well, actually only sort of truly deleted, because Windows only appears to remove the file entry from the directory, but in fact that entry is merely hidden and actually still exists and attempting to create a file with the same name will return an access denied error. How long it silently exists for depends on a range of factors, but put it this way: if your code loops creating and deleting the same file name as you might when operating a lock file, you're going to see lots of random spurious access denied errors. The described behavior is similar to attempt to open a file from other flow, during execution DeleteFile more. As DeleteFile it CreateFile + NtSetInformationFile (FileDispositionInformation) + CloseHandle. And here if between NtSetInformationFile and CloseHandle  tries to open a file - receives access denied.