Why can't I create a txt file after having just deleted it?

Question

My program creates a log file when it starts. The user has the option through settings to "clear the log" which calls a method to delete the log file.

        //calls for a YesNo prompt to delete log or not
        result = objectMessageBox.ReturnDeleteLogPrompt();

        if (result == DialogResult.Yes)
        {
            //throw prompt
            if (File.Exists(objectLog.GetLogLocation()) == true)
            {
                try
                {                        
                    //delete the log file
                    File.Delete(objectLog.GetLogLocation());                        

                    //throw balloon tip saying log was cleared
                    ShowBalloonTip("LogCleared");
                }
                catch (Exception ee)
                {
                    MessageBox.Show("Error thrown deleting log: " + ee);
                    System.Windows.Forms.Clipboard.SetText(ee.ToString());
                }
            }
        }

Because I have deleted the log file entirely I need to then recreate it. So I call a method that has this:

try
        {
            //we create a new log file so it seems that the log has just been cleared
            objectLog.CreateLog();
        }
        catch (Exception ee)
        {
            MessageBox.Show("Error occured while clearing log:\n" + ee);
        }

But when it attempts to recreate the log file it throws an error that says:

"System.IO.IOException: The process cannot access the file '~~' because it is being used by another process."

So it seems that during my call to delete the file it keeps accessing it? Do I need to dispose of something when I call the file.delete?

Answer 1

I don't know the details, but there are numerous reasons for why a filename isn't immediately available for recreation after deleting an existing file:

• The delete operation is still pending by the operating system
• An antivirus program or similar security feature opened up the file in response to it being deleted, for pre-deletion analysis
• An antivirus program or similar security feature already had the file open while you were using it, and is still in the progress of responding to your deletion request

Mercurial had this problem on Windows as well. If you executed one command that locked the repository (which was done using temporary files), and then immediately executed another command that either needed to lock, or at least ensure no lock was present, it could fail with the same type of error, the file was in use, even though this was two distinct processes and the first had already exited.

In other words, the timeline was as follows:

• hg.exe instance #1 starts up, locks the repository by creating the temp file
• hg.exe does what it needs to do
• hg.exe deletes the file, then exits
• hg.exe instance #2 starts up, attempts to lock the repository, fails because file is in use

Their hack to "fix" this was to simply pick a random filename that wasn't used in the directory, rename the file to that name, and then delete it. This did not solve the problem of the file lingering for a short while, but it did free up the filename and make it available for new files right away.