Why can't I create a txt file after deleting it?

Question

My program creates a log file when it starts. The user has the option to use the "clear log" settings, which calls the 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()); } } } 

Since I completely deleted the log file, I need to recreate it. Therefore, 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 he tries to recreate the log file, he gives an error message:

"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, he continues to access it? Do I need to dispose of something when I call file.delete ?

Answer 1

Instead of deleting and re-creating the same file, can you just clear it?

Something like this should work for you:

 FileStream f = File.Open(@[filename], FileMode.Create); f.Close(); 

Answer 2

I don’t know the details, but there are many reasons why the file name is not immediately available for rest after deleting the existing file:

• Uninstall operation still awaiting operating system
• An antivirus program or similar security feature opened the file in response to its deletion, for analysis before deletion
• An antivirus program or similar security feature has already opened the file during its use and is still in the process of responding to your deletion request.

Mercurial also had this problem on Windows. If you run one command that blocked the repository (this was done using temporary files), and then immediately ran another command, which was either necessary to block, or at least to ensure that there was no blocking, it may fail with the same type of errors, the file was used, although it was two separate processes, and the first one was already released.

In other words, the timeline was as follows:

• starts instance # 1 hg.exe, blocks the repository, creating a temporary file
• hg.exe does what it needs to do
• hg.exe deletes the file, then terminates
• starts instance # 2 hg.exe, tries to lock the repository, fails because the file is being used

To crack them, the “fix” was simply to select an arbitrary file name that was not used in the directory, rename the file to that name, and then delete it. This did not help to solve the file shortage problem, but it freed the file name and immediately released it for new files.

Answer 3

There is already an accepted answer, but maybe someone finds it useful (or laugh at it if I missed something obvious again and completely lost my time)

I had the impression that File.Delete would either delete the file, or then return, or otherwise throw an exception - until I read this stream.

The Windows API mentions that by calling DeleteFile , the file is "marked for deletion when closing" because it allows deletion in an open file. After the file is marked for deletion, an attempt to open it will fail with the "Access denied" error. When the last handle to this file is closed, the file is actually deleted.

If windows actually delete the file before returning from the last CloseHandle call to the file, theoretically this code ensures that the file will be deleted below the using block:

 using (File.Open(path, FileMode.Open, FileAccess.Read, FileShare.Delete)) { File.Delete(path); } 

File.Open will fail if a file is opened in another process.

Note the difference in the fact that File.Delete even succeeds if the file does not exist (if the directory does not exist).

Answer 4

You can use System.IO.FileInfo.Delete to delete the file, and then System.IO.FileInfo.Refresh () before creating the file again. The update should stop throwing when the file is recreated. Or, as nycdan says, use the FileMode.Create enumeration.