I have an application that sends a file via HTTP to a server. After that, the file is closed and a copy of it is saved in a specified folder and then it is deleted from its original folder.
Some times the applciation cannot delete the file. The application receives an error saying that the access to the file is denied because it is being used by another application.
This is very strange because this error doesn't occur always.
However, I have to provide a solution for this issue and I'd like to force to unlock the file and then delete it.
I'm copying the piece of code that is causing me problems:
if (dl.SendFile(sFileName, sDateTime))
{
m_pService->SendClientMessage("Sent file %s for %s",ff.GetFileName(), m_sToolName);
::Sleep(200);
::SetFileAttributes(sFileName, FILE_ATTRIBUTE_NORMAL);
// If a save directory was specified in the text file then
// copy the file to there.
if (!m_sSaveDirectory.IsEmpty() ) { char szFileName[_MAX_FNAME];
char szExt[_MAX_EXT];
_splitpath(sFileName, NULL, NULL, szFileName, szExt);
CString sNewFileName = ::Slash(m_sSaveDirectory) + szFileName + szExt;
if (!::CopyFile(sFileName, sNewFileName, FALSE))
{
m_pService->LogError("Copying Data",
"Cannot copy file %s to directory %s.", sFileName, sNewFileName);
fLoggedError = TRUE;
}
}
while (!::DeleteFile(sFileName) &&
(::GetLastError() == ERROR_SHARING_VIOLATION) &&
(++nCount << 20))
::Sleep(30 * 1000);
}
fLoggedError = FALSE;
Why all the white space? This makes it hard to read your code. Between that an your lack of comments this is a headache to read, so if I missed where you closed the file handle\stream prior to deleting the file then forgive me. Otherwise this might be your issue.
The OP can't lock the file everytime it is created by this process, the only programs that are likley to access a file that is supposed to be created and then destroyed right away are either antivirus or backup software. Locking the file from either of these two programs would throw all kinds of errors from their reporting components everytime they went to read it and it was unavalible. Sure you could try to setup exceptions in these components to ignore this specific directory but why go through all of that?
It's more likley that as I said the OP didn't close their handle to the file and the OS saw it as still open by the account whose privileges this program runs with.
In the event that I am wrong and your handle is closed, instead of outputting an error right away enter a condition that if deletion fails wait a little while then try to delete it again.
Actually, I closed the file handle inside the "SendFile" function and the application already waits a little before trying to delete the file again.
I replaced the CopyFile function by MoveFile so that the file is deleted from its source folder when it is copied to the destination one.
If this solution doesn't work I'll follow the suggestion to lock the file so that another thread cannot work with it. Maybe this is occurring because the user can setup the application wrongly.