DeleteFile fails on recently closed file - c++

I have a single threaded program (C++, Win32, NTFS) which first creates a quite long temporary file, closes it, opens for read, reads, closes again and tries to delete using DeleteFile().
Usually it goes smoothly, but sometimes DeleteFile() fails, and GetLastError() returns ERROR_ACCESS_DENIED. File is not read-only for sure. It happens on files on any size, but the probability grows with the file size.
Any ideas what may be locking the file? I tried WinInternals tools to check and found nothing suspicious.

Windows is notorious for this issue. SQLite handles the problem by retrying the delete operation every 100 milliseconds up to a maximum number.
I believe if you are sure that you have no open handles, doing this in your implementation will save you some headaches when things like antivirus software open the file.
For reference, the comment from SQLite source:
/*
** Delete the named file.
**
** Note that windows does not allow a file to be deleted if some other
** process has it open. Sometimes a virus scanner or indexing program
** will open a journal file shortly after it is created in order to do
** whatever it does. While this other process is holding the
** file open, we will be unable to delete it. To work around this
** problem, we delay 100 milliseconds and try to delete again. Up
** to MX_DELETION_ATTEMPTs deletion attempts are run before giving
** up and returning an error.
*/

Just a wild guess - do you have any anti-virus software installed? Have you tried disabling any real-time protection features in it, if you do?

I believe this is covered in Windows Internals. The short story is that even though you've called CloseHandle on the file handle, the kernel may still have outstanding references that take a few milliseconds to close.
A more reliable way to delete the file when you're done is to use the FILE_FLAG_DELETE_ON_CLOSE flag when opening the last handle. This works even better if you can avoid closing the file between reads/writes.
#include <windows.h>
#include <stdio.h>
int wmain(int argc, wchar_t** argv)
{
LPCWSTR fileName = L"c:\\temp\\test1234.bin";
HANDLE h1 = CreateFileW(
fileName,
GENERIC_WRITE,
// make sure the next call to CreateFile can succeed if this handle hasn't been closed yet
FILE_SHARE_READ | FILE_SHARE_DELETE,
NULL,
CREATE_ALWAYS,
FILE_FLAG_SEQUENTIAL_SCAN | FILE_ATTRIBUTE_TEMPORARY,
NULL);
if (h1 == INVALID_HANDLE_VALUE)
{
fprintf(stderr, "h1 failed: 0x%x\n", GetLastError());
return GetLastError();
}
HANDLE h2 = CreateFileW(
fileName,
GENERIC_READ,
// FILE_SHARE_WRITE is required in case h1 with GENERIC_WRITE access is still open
FILE_SHARE_WRITE | FILE_SHARE_READ | FILE_SHARE_DELETE,
NULL,
OPEN_EXISTING,
// tell the OS to delete the file as soon as it is closed, no DeleteFile call needed
FILE_FLAG_DELETE_ON_CLOSE | FILE_FLAG_SEQUENTIAL_SCAN | FILE_ATTRIBUTE_TEMPORARY,
NULL);
if (h2 == INVALID_HANDLE_VALUE)
{
fprintf(stderr, "h2 failed: 0x%x\n", GetLastError());
return GetLastError();
}
return 0;
}

Add a MessageBox() call before you invoke DeleteFile(), When it shows up, run the sysinternals tool Process Explorer.
Search for an open handle to the file. In all probability you have not closed all handles to the file...

Maybe the changes are still cached and haven't been saved yet?
You can check this by adding a WaitForSingleObject on the file handle to be sure.

You may have a race condition.
1. Operating system is requested to write data.
2. Operating system is requested to close file. This prompts final buffer flushing. The file will not be closed until the buffer flushing is done. Meanwhile The OS will return control to the program while working on buffer flushing.
3. Operating system is requested to delete the file. If the flushing is not done yet then the file will still be open and the request rejected.

#include <iostream>
#include <windows.h>
int main(int argc, const char * argv[])
{
// Get a pointer to the file name/path
const char * pFileToDelete = "h:\\myfile.txt";
bool RemoveDirectory("h:\\myfile.txt");
// try deleting it using DeleteFile
if(DeleteFile(pFileToDelete ))
{
// succeeded
std::cout << "Deleted file" << std::endl;
}
else
{
// failed
std::cout << "Failed to delete the file" << std::endl;
}
std::cin.get();
return 0;
}

Related

Windows 8: CreateFile() returns INVALID_HANDLE_VALUE, immediate GetLastError shows 0

I am opening a file with CreateFile on Windows 8 from within a printer filter environment. The code is effectively straight C, even though the filter is built in C++. CreateFile returns INVALID_HANDLE_VALUE but an immediate call to GetLastError returns 0. I have seen this before, back in the old NT4 days (and through to Windows 7) if a directory of the same name as the file existed, a file open attempt would fail with error 0; but I have checked and the file name is different from any subdirectories in the destination directory.
Code:
io_buf[fh].fh = CreateFile(name, GENERIC_READ|GENERIC_WRITE, 0, p_sa,
CREATE_ALWAYS, 0, (HANDLE)0);
io_buf[fh].read_mode = FALSE;
io_buf[fh].file_start = 0L;
io_buf[fh].folder = 0;
if (io_buf[fh].fh == INVALID_HANDLE_VALUE)
{
LogMsg("BufCreate: CreateFile failed (%ld); retrying with SharedWrite\r\n", GetLastError());
io_buf[fh].fh = CreateFile(name, GENERIC_READ|GENERIC_WRITE, FILE_SHARE_READ | FILE_SHARE_WRITE, p_sa,
CREATE_ALWAYS, 0, (HANDLE) 0);
}
if (io_buf[fh].fh == INVALID_HANDLE_VALUE)
{
LogMsg("BufCreate: CreateFile failed (%ld)\r\n", GetLastError());
return (Vers_FAILURE);
}
LogMsg output:
Render 15:41:46.715: BufCreate: CreateFile failed (0); retrying with SharedWrite
Render 15:41:46.715: BufCreate: CreateFile failed (0)
Because this occurs relatively randomly, sending it to MS would not work; they'd fire it back to me with a "no rep" and I'd get dinged for the SRX. Has anyone got any clue on how I would proceed?
This is vexing. Turns out that I was not writing the file where I thought I was, and that's why it failed. But it should have returned error 5 (Access denied), and I was led up a stump because of this bedamned 0 in GetLastError.
For what it's worth: I had created a path to a temp directory. Because my security context at the time was LocalSystem (I'm in the PrinterPipeline service), that file was in c:\Windows\System32\Services\LocalService\AppData\Local\Temp. No ordinary user can reach that space, and the attempt will quite possibly leave your OS hooped. I had changed to user security context to write to C:\Temp, and was getting a failure because I had forgotten to change my filename to C:\Temp. The error 0 made it look like possibly I was faced with file system redirection mapping c:\temp into LocalService space.
Correcting that so that I was actually writing where I thought I was got rid of the failure... but I still don't understand why Windows was handing me back an error 0.

I'm using QDir().isReadable to check if a drive is readable. In the Qt Creator it runs fine, but when I run the exe it keeps giving me errors

I'm using it like this:
if(QDir("G:/").isReadable()){
qDebug("G Is readable!"); //Do something with G:/
}
As I said, in Qt Creator it runs fine without a problem, it checks if the drive is readable, and if so it prints it to the console, if not, it does nothing.
But when I run the .exe file, it keeps giving me errors each time it does the check (every 2 seconds) if the drive isn't readable.
"There is no disk in the drive. Please insert a disk into drive G:."
I don't want this error to keep appearing, what do I do?
Edit: I think it's the isReadable function that causes the problem, is there any other way to do what I want to do? Or maybe should I write the code myself?
This message is generated by Windows.
There is a workaround for users that have applications that cannot be fixed. The error messages may be suppressed by setting 2 to registry key ErrorMode in:
Computer\HKEY_LOCAL\MACHINE\SYSTEM\CurrentControlSet\Control\Windows
It looks that if QDir::isReadable() is called after removing the media it triggers that error. QDir::exists() always returns true if the drive letter is present in the system, so it cannot be used here.
For now I see that it is possible to check removable media using native Windows API, see the answer to How to detect if media is inserted into a removable drive/card reader
The following code is able to detect that the media is removed without triggering the error:
#include <windows.h>
HANDLE hDevice = CreateFile (L"\\\\.\\G:", // like "\\.\G:"
FILE_READ_ATTRIBUTES, // read access to the attributes
FILE_SHARE_READ | FILE_SHARE_WRITE, // share mode
NULL, OPEN_EXISTING, 0, NULL);
if (hDevice == INVALID_HANDLE_VALUE) {
// not valid device
return;
}
WORD cbBytesReturned;
bool bSuccess = DeviceIoControl (hDevice, // device to be queried
IOCTL_STORAGE_CHECK_VERIFY2,
NULL, 0, // no input buffer
NULL, 0, // no output buffer
(LPDWORD)&cbBytesReturned, // # bytes returned
NULL); // synchronous I/O
CloseHandle(hDevice); // close handle
if (bSuccess && QDir("G:/").isReadable()) {
// G is readable
}

Portable temporary files with C++ (C++ standard libraries or Boost)?

Is there a portable way of creating temporary files with C++ that get automatically deleted when the program terminates (regardless of whether it crashes, gets killed, or just reaches return 0; in main().).
On Unix systems, I can open a file, delete it and then keep the still existing handle. This works with FILE *, std::fstream etc.
On Windows, this appears not to work. The only way I found is using CreateFile with the FILE_FLAG_DELETE_ON_CLOSE flag.
Is there something smarter that (1) works both on Linux and Windows, (2) has the "the file is removed on when the program terminates" behaviour as on Linux. I would be fine with #ifdef code as long as the file type that I work with is the same on both systems (e.g. std::fstream or FILE *).
I know about this solution, but this appears only to work on graceful exits and would require me to either set up central handlers and manage all temporarily opened files.
Edit: Rephrased the question to "how can I get files on Windows that are automatically removed as removed-but-still-open files in Linux.
http://www.cplusplus.com/reference/cstdio/tmpfile/
Creates a temporary binary file, open for update ("wb+" mode, see
fopen for details) with a filename guaranteed to be different from any
other existing file.
The temporary file created is automatically deleted when the stream is
closed (fclose) or when the program terminates normally. If the
program terminates abnormally, whether the file is deleted depends on
the specific system and library implementation.
For abnormal termination, handle std::terminate by using: http://en.cppreference.com/w/cpp/error/set_terminate
Clean up the file with std::remove and then re-throw. I haven't tested this abornmal termination stuff yet but it should work. The temporary file creation works for sure. I've used it before.
It can be wrapped in a streambuf for usage with streams.
Also as a partial solution you can write a class, that deletes the file on destruction. On windows you can use MoveFileExW(filepathFull, NULL, MOVEFILE_DELAY_UNTIL_REBOOT) if that fails to have the file deleted on reboot. All of this can be hidden in the class. See for example: tmpfile.h tmpFile.cpp
Alternatively you can use something like:
struct TmpFile{
FILE* file;
TmpFile(std::string path){
#ifdef _WIN32
HANDLE handle = CreateFile(path.c_str(), GENERIC_READ | GENERIC_WRITE, 0, 0,
OPEN_ALWAYS, FILE_ATTRIBUTE_TEMPORARY | FILE_FLAG_DELETE_ON_CLOSE, 0);
if(handle == INVALID_HANDLE_VALUE) throw "Error";
int fd = _open_osfhandle((intptr_t)h, _O_APPEND | _O_RDONLY);
if(fd == -1){ CloseHandle(handle); throw "Error"; }
file = _fdopen(fd, "a+");
if(f == NULL){ _close(fd); throw "Error"; }
#else
file = fopen(path.c_str(), "w+");
unlink(path.c_str());
#endif
}
~TmpFile(){
fclose(file);
}
};
Check the access modifiers and adjust to your needs (especially the error handling) This has the nice properties of RAII and will delete the file even in exception cases. However some failures where the dtor is not called will leak the handle in which case the file might not be deleted on windows.
The Win32 handling is taken from here: https://stackoverflow.com/a/7369662/1930508 Check the explanations there.

Deleting a file with an open Handle

I shouldnt be able to delete a file with an open handle, correct? So i create a file, then i straight away try to delete it, expecting this to fail. Or am i wrong and the handle doesnt have to be closed before deleting the file?
HANDLE hFile = CreateFile (TEXT(file),
GENERIC_WRITE,
0,
NULL,
OPEN_ALWAYS,
FILE_ATTRIBUTE_NORMAL,
NULL);
if (hFile == INVALID_HANDLE_VALUE)
{
//FAIL
}
if(DeleteFile(file))
{
//Should it ever get here cos i dont close the handle?
}
It depends on how the file has been opened. If the share mode has FILE_SHARE_DELETE specified, then it may be deleted by others.
Even if you memory map the file, and it has been opened with this flag (and read/write sharing), then it can still be deleted by the shell (at least I've tried this and it happens, but perhaps the file has simply been renamed and moved to the recycle bin). In such cases, subsequently accessing the memory will result in an 'InPageError' C-style exception.
Yes, it would fail.
The DeleteFile function fails if an application attempts to delete a
file that is open for normal I/O or as a memory-mapped file.
Have you tried this? MS documentation states that:
The DeleteFile function fails if an application attempts to delete a file that is open for normal I/O or as a memory-mapped file.
So if you're not getting that behaviour I'd suggest it's down to the way you've opened the file. Are you sure that your check on whether the file is open is completely comprehensive?Have you tried writing to the file first? Can you see the file outside of your own code? (i.e. from Explorer) Look here for more details.

CreateFile() Failed With GetLastError() = 5

I have written a sample application to read the file from the other file. When I run this application form virtual machine I am getting Access denied. Below is the code.
int _tmain(int argc, _TCHAR* argv[])
{
WCHAR *wcsPath = L"\\\\150.160.130.22\\share\\123.XML";
HANDLE hFile = CreateFileW(wcsPath,
GENERIC_READ,
FILE_SHARE_READ,
NULL,
OPEN_EXISTING,
0,
0);
if (NULL == hFile)
{
printf("failed - %d", GetLastError());
}
return 0;
}
Please let me know any changes.
Error code 5 stands for "Access is Denied". You should check your user's access rights.
I believe the documentation for CreateFile holds the answer.
It may be that your dwShareMode is causing the problem. Using FILE_SHARE_READ there says, "allow other openers to open the file for READ access". If you do not specify FILE_SHARE_WRITE` , then other openers will not be able to open the file for writing - your call would prevent that.
But, CreateFile, I believe, also fails when the sharemode would be violated by prior openers. If this is true, then if another application already has the file open for write access, then your call to CreateFile will fail, if you specify dwShareMode = FILE_SHARE_READ. Do you see? You may need to specify FILE_SHARE_WRITE | FILE_SHARE_READ for that dwShareMode parameter.
Try it.
The error output of CreateFileW() is INVALID_HANDLE_VALUE, not NULL. Now, NULL definitely sounds like a wrong value for a file handle too, but still.
Is the pasted code snippet exactly the content of your program, or a retelling?
EDIT: I see there's a VM involved. Can you open the file in Notepad from the virtual machine where the program is running and erroring out?