13

When I try to delete a file occurs the following exception:

The process cannot access the file '' because it is being used by another process.

My code looks like:

string[] files = Directory.GetFiles(@"C:\SEDocumentConverter\SOURCE");
foreach (string file in files)
{               
   File.Delete(file);
}

How can I solve this problem?

Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
Suresh Chaudhary
  • 1,609
  • 5
  • 25
  • 40
  • 2
    Find out which other process is accessing the file, and stop it doing so. – David Heffernan Mar 08 '11 at 12:48
  • Do you have one of the files open in an editor? Were you working with one of the files earlier in your program and perhaps leave a stream open? – tvanfosson Mar 08 '11 at 12:50
  • Is the error as you have typed - i.e. an empty filename is returned or have you just removed the name for the question? – ChrisF Mar 08 '11 at 12:50
  • you can follow this solution http://stackoverflow.com/questions/13262548/delete-a-file-being-used-by-another-process/21137207#21137207 – kplshrm7 Feb 25 '16 at 11:03

6 Answers6

9

There is no way to delete a file that's currently being used by another process. You have to close whatever program has that file open first, before you can delete it.

If you don't already know which program that is, you can figure it out using Handle or Process Explorer.

DDA
  • 991
  • 10
  • 28
Cody Gray - on strike
  • 239,200
  • 50
  • 490
  • 574
  • 1
    With Process Explorer you can also remove the handle without closing the program (if you are sure that the program can happily live without the handle). – René Dec 16 '21 at 08:52
4

You can P/Invoke the Windows MoveFileEx function, and use the MOVEFILE_DELAY_UNTIL_REBOOT flag, with a NULL destination name. This will delete the file when you reboot.

Polyfun
  • 9,479
  • 4
  • 31
  • 39
  • 2
    Note that, as the documentation indicates, this flag can only be used if the process is running in the context of a user who is an Administrator. And this is probably overkill for standard document files. You shouldn't be moving paging files from a .NET application in the first place. – Cody Gray - on strike Mar 09 '11 at 03:50
0

Another way is to find all open handles to the file and close them forcibly.

Works nice for you, bad for any apps which were using the file.

Could try that in UI with SysInternals ProcessExplorer.

hypersw
  • 475
  • 3
  • 9
0

If the file is being used you're out of luck in trying to delete it. I can't tell you based on your code what process might be using the file(s), but try looking here or here or here, or at any of the other questions that show up as related to this one for guidance regarding this issue, and by all means follow the guidance from @Cody Gray about using Process Explorer.

Community
  • 1
  • 1
Zann Anderson
  • 4,767
  • 9
  • 35
  • 56
  • Wow, that's incredible. There are at least 3 other questions with titles *exactly matching* the original title of this question. – Cody Gray - on strike Mar 08 '11 at 12:54
  • 1
    Yeah, who knew? And as a note to @Suresh - you should see a list of questions that Stack Overflow thinks are like the one you're asking when you type in the subject line for your question. If you check those out first, you might find your answer and save yourself the trouble of posting. – Zann Anderson Mar 08 '11 at 13:01
0

slightly off topic: But it seems from your code that you are trying to delete all files of your folder. Well instead of deleting them one by one we have another method Directory.Delete(path, True) which will delete the directory as contained in the string named path. Then you may recreate the directory if you want. But your problem may persist here too.

-1

Just rename this file. This will do the thing for whoever tries to write to that location.

Notes:

1) Of course the file is not deleted physically yet. Nice to do the MoveFileEx trick mentioned here around to complete the job.

2) If you want to delete a locked file to write smth new in its place (e.g. during build), just rename the file to a GUID name. If you need the folder to be clean, either use an ignored extension / hidden attribute, or rename the file to a path under %TEMP% (if on the same drive).

3) Not all locked files can be renamed, but it works for me for like 90% practical applications. You can move a file without affecting an open read/write/execute handle, it will continue working with the moved file just good (if moved within the same NTFS volume of course).

4) That's what Windows Installer would basically do before it asks you to please reboot somewhen soon: move the file away from your eyes, schedule to be removed upon reboot. Usually the newly-installed app can be used right away.

Practical Use:

My favorite is with MSBuild. Overriding the <Copy/> task with this stuff makes all the build go linux-way. You don't care if a prev version is still running somewhere, can still build&run. The old app keeps using the old version of the files. The new app loads the newly-written version.

Might be moving to %TEMP% if on the same drive (not my case though). I'd just rename them to an extension which is ignored with the current source control client.

hypersw
  • 475
  • 3
  • 9