W
Warren Stanley
Guest
Windows 7 is able to get files in a state where nothing can be done to the file. It can’t be deleted, renamed, read, permissions can’t be viewed and ownership can’t be taken (even by an administrator). Any attempt to do something to the file results in an error of access denied.
This is because the file is in a DELETE PENDING state. Normally this only occurs for a short time while one process has the file open and another tries to delete the file. Once the file is no longer held open, it should be removed by the OS. Sometimes it does not, and a system reboot is required to be able to fix the problem. Once the OS has restarted, the file is no longer in a DELETE PENDING state, the file has not been removed, but now it can be deleted or accessed in any other way.
I had posted a thread about this issue in Visual Studio Development > Visual Studio General Questions (but it has since been moved), mainly because that is how the problem was discovered, but I have also created a c++ program that reproduces the issue, and other than being compiled using Visual Studio, it has nothing to do with Visual Studio. To me, this looks like an OS issue. For a Visual Studio focused look at the problem see https://social.msdn.microsoft.com/Forums/vstudio/en-US/1fe254fe-51ba-42b5-b710-c1e6b3015997/file-delete-pending-problem?forum=visualstudiogeneral.
I have only been able to reproduce the issue on systems with the following:
Another requirement is that the file that will get locked up will be indexed by the Windows Indexing Service. Use the Indexing Options control panel to find an indexed directory, or setup one up to be indexed.
In reproducing this problem, I have tried using a ramdisk (Tools and utilities for Windows) to make it easier to see on other hardware, but using this particular version, the Windows Indexer does not seem to join the party, and so the problem is not reproduced.
Following is the small VS2010 c++ program that I have created that makes the problem happen (on our systems).
#include <SDKDDKVer.h>
#include <windows.h>
#include <stdio.h>
#include <tchar.h>
int _tmain(int argc, _TCHAR* argv[])
{
if (argc < 2)
{
_tprintf_s(_T("\"%s\" <filename> [-/+<extension for rename>]\n"), argv[0]);
return 0;
}
_TCHAR *sFileName = argv[1];
_TCHAR sNewfileName[255];
_tcscpy_s(sNewfileName, sFileName);
_TCHAR *sExtension = _T(".original");
bool bAddExtension = true;
if (argc >= 3)
{
sExtension = argv[2];
switch(sExtension[0])
{
case '-':
{
_TCHAR *pEndOfName = _tcsstr(sNewfileName, _T("."));
*pEndOfName = 0;
++sExtension;
break;
}
case '\0':
printf_s("Invalid extension\n");
return 0;
default:
case '+':
++sExtension;
break;
}
}
_tcscat_s(sNewfileName, sExtension);
_tprintf_s(_T("Original filename: %s\nRename filename: %s\n"), sFileName, sNewfileName);
for (int i=0; i < 100; ++i)
{
{
HANDLE hHandle = CreateFile(sFileName, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
char data[] = "test";
DWORD dwDataWritten;
WriteFile(hHandle, data, _countof(data), &dwDataWritten, NULL);
CloseHandle(hHandle);
}
if (MoveFile(sFileName, sNewfileName) == FALSE)
{
printf_s("Error found on try %d!!!\nIt probably occurred on the last try\n", i);
return 0;
}
DeleteFile(sNewfileName);
}
printf_s("Problem not detected\n");
return 0;
}
All this program does is create a file, write some contents, close the file, then rename (move) the file and delete the renamed file. It does this many times to give the OS a chance to lose track of the file to be deleted as is does not always occur on the first attempt. The file that gets locked up in the DELETE PENDING state is the moved (or renamed) file.
Using SysInternals Process Monitor I have seen that if I pass in a filename that ends in .dll and is in an indexed directory, McAfee scans the file, then the Windows Indexing Service indexes the file, and sometimes it gets locked up in a DELETE PENDING state. If the filename passed in ends in .txt, McAfee does not scan the file, and then it does not get locked up. If the file location is not an indexed location, the result is no lockup and the indexing service does not look at the file.
Using SysInternals Process Explorer, I have seen that the DELETE PENDING file is not open by anything, there are no file handles open on the file and my program has finished (it is no longer running).
From what I can see, the virus scanner is involved, but I don’t know if it is this specific virus scanner or any virus scanner. It is also a case of the virus scanner has released it’s file handles on the file (and so has everything else). Since the file is still not removed after this, to me this makes it an OS problem, even if a third party virus scanner is needed to setup the problem until it is fully understood.
Any additional information about other systems where this problem can be reproduce would be appreciated, or an indication this problem is and OS issue and has or can be fixed.
Thank you,
Warren.
More...
This is because the file is in a DELETE PENDING state. Normally this only occurs for a short time while one process has the file open and another tries to delete the file. Once the file is no longer held open, it should be removed by the OS. Sometimes it does not, and a system reboot is required to be able to fix the problem. Once the OS has restarted, the file is no longer in a DELETE PENDING state, the file has not been removed, but now it can be deleted or accessed in any other way.
I had posted a thread about this issue in Visual Studio Development > Visual Studio General Questions (but it has since been moved), mainly because that is how the problem was discovered, but I have also created a c++ program that reproduces the issue, and other than being compiled using Visual Studio, it has nothing to do with Visual Studio. To me, this looks like an OS issue. For a Visual Studio focused look at the problem see https://social.msdn.microsoft.com/Forums/vstudio/en-US/1fe254fe-51ba-42b5-b710-c1e6b3015997/file-delete-pending-problem?forum=visualstudiogeneral.
I have only been able to reproduce the issue on systems with the following:
- a high performance (enough) SSD, like the OCZ Vertex 3 or a Samsung SSD 850; and
- virus scanning software
specifically McAfee VirusScan Enterprise 8.8.06000
Another requirement is that the file that will get locked up will be indexed by the Windows Indexing Service. Use the Indexing Options control panel to find an indexed directory, or setup one up to be indexed.
In reproducing this problem, I have tried using a ramdisk (Tools and utilities for Windows) to make it easier to see on other hardware, but using this particular version, the Windows Indexer does not seem to join the party, and so the problem is not reproduced.
Following is the small VS2010 c++ program that I have created that makes the problem happen (on our systems).
#include <SDKDDKVer.h>
#include <windows.h>
#include <stdio.h>
#include <tchar.h>
int _tmain(int argc, _TCHAR* argv[])
{
if (argc < 2)
{
_tprintf_s(_T("\"%s\" <filename> [-/+<extension for rename>]\n"), argv[0]);
return 0;
}
_TCHAR *sFileName = argv[1];
_TCHAR sNewfileName[255];
_tcscpy_s(sNewfileName, sFileName);
_TCHAR *sExtension = _T(".original");
bool bAddExtension = true;
if (argc >= 3)
{
sExtension = argv[2];
switch(sExtension[0])
{
case '-':
{
_TCHAR *pEndOfName = _tcsstr(sNewfileName, _T("."));
*pEndOfName = 0;
++sExtension;
break;
}
case '\0':
printf_s("Invalid extension\n");
return 0;
default:
case '+':
++sExtension;
break;
}
}
_tcscat_s(sNewfileName, sExtension);
_tprintf_s(_T("Original filename: %s\nRename filename: %s\n"), sFileName, sNewfileName);
for (int i=0; i < 100; ++i)
{
{
HANDLE hHandle = CreateFile(sFileName, GENERIC_WRITE, 0, NULL, CREATE_ALWAYS, FILE_ATTRIBUTE_NORMAL, NULL);
char data[] = "test";
DWORD dwDataWritten;
WriteFile(hHandle, data, _countof(data), &dwDataWritten, NULL);
CloseHandle(hHandle);
}
if (MoveFile(sFileName, sNewfileName) == FALSE)
{
printf_s("Error found on try %d!!!\nIt probably occurred on the last try\n", i);
return 0;
}
DeleteFile(sNewfileName);
}
printf_s("Problem not detected\n");
return 0;
}
All this program does is create a file, write some contents, close the file, then rename (move) the file and delete the renamed file. It does this many times to give the OS a chance to lose track of the file to be deleted as is does not always occur on the first attempt. The file that gets locked up in the DELETE PENDING state is the moved (or renamed) file.
Using SysInternals Process Monitor I have seen that if I pass in a filename that ends in .dll and is in an indexed directory, McAfee scans the file, then the Windows Indexing Service indexes the file, and sometimes it gets locked up in a DELETE PENDING state. If the filename passed in ends in .txt, McAfee does not scan the file, and then it does not get locked up. If the file location is not an indexed location, the result is no lockup and the indexing service does not look at the file.
Using SysInternals Process Explorer, I have seen that the DELETE PENDING file is not open by anything, there are no file handles open on the file and my program has finished (it is no longer running).
From what I can see, the virus scanner is involved, but I don’t know if it is this specific virus scanner or any virus scanner. It is also a case of the virus scanner has released it’s file handles on the file (and so has everything else). Since the file is still not removed after this, to me this makes it an OS problem, even if a third party virus scanner is needed to setup the problem until it is fully understood.
Any additional information about other systems where this problem can be reproduce would be appreciated, or an indication this problem is and OS issue and has or can be fixed.
Thank you,
Warren.
More...