How do I check whether File.Delete() will succeed without trying it, in C#?

Question

In C#, System.IO.File.Delete(filePath) will either delete the specified file, or raise an exception. If the current user doesn't have permission to delete the file, it'll raise an UnauthorizedAccessException.

Is there some way that I can tell ahead of time whether the delete is likely to throw an UnauthorizedAccessException or not (i.e. query the ACL to see whether the current thread's identity has permission to delete the specified file?)

I'm basically looking to do:

if (FileIsDeletableByCurrentUser(filePath)) {
    /* remove supporting database records, etc. here */
    File.Delete(filePath);
}

but I have no idea how to implement FileIsDeletableByCurrentUser().

It's pretty difficult to handle race conditions. What if the file "was" deletable at the time you are evaluating `FileIsDeletableByCurrentUser` but right after it, some other process locks the file? — Mehrdad Afshari, Sep 18 '09 at 12:08
You also cannot delete the file if it is open by another process (like say IIS or office). It may be the same exception but you couldnt tell simply by looking at permissions — ryber, Sep 18 '09 at 12:16
Are you sure that just using a try/catch for the specific exceptions is not the correct way to handle this? It seems like you are trying to re-invent the wheel here. — StingyJack, Sep 18 '09 at 12:20
This Microsoft doc link must be helpful if you want to write code check permissions by yourself: https://learn.microsoft.com/en-us/dotnet/api/system.security.permissions.fileiopermission?view=netframework-4.7.2 — QMaster, Jan 21 '19 at 13:35

score 18 · Answer 1 · edited Jan 20 '16 at 09:26

18

The problem with implementing FileIsDeletableByCurrentUser is that it's not possible to do so. The reason is the file system is a constantly changing item.

In between any check you make to the file system and the next operation any number of events can and will happen. Including ...

Permissions on the file could change
The file could be deleted
The file could be locked by another user / process
The USB key the file is on could be removed

The best function you could write would most aptly be named FileWasDeletableByCurrentUser.

edited Jan 20 '16 at 09:26

Matt Wilko

26,994
10
93
143

answered Sep 18 '09 at 14:13

JaredPar

733,204
149
1,241
1,454

3

Voted up because your proposed function name is both humorous and insightful. – Dylan Beattie Sep 18 '09 at 20:43
Silly reasoning.... "Is" would be fine because you are checking the permission at that exact point. Otherwise we would have file api functions called "ReadOldData" just in case the data changes between reading it and actually using it. – musefan Jun 27 '19 at 09:52

score 9 · Answer 2 · edited Dec 04 '22 at 14:38

9

Have you tried System.IO.File.GetAccessControl(filename) it should return a FileSecurity with information about the permissions for that file.

edited Dec 04 '22 at 14:38

Andrew Morton

24,203
9
60
84

answered Sep 18 '09 at 12:11

Dale

12,884
8
53
83

score 2 · Answer 3 · edited Jun 15 '15 at 11:28

As stated above. Lookup the file permissions and compare with the user who is running the application.

You could always use this aproach as well

bool deletemyfile()  
{  
    try  
    {  
        ...delete my file  
        return true;  
    }  
    catch  
    {  
        return false;  
    }  
}

if it returns false you know it failed if it returns true then.. it worked and file is gone. Not sure what you're after exactly but this was the best I could think of

score 2 · Answer 4 · answered Sep 18 '09 at 12:28

Strictly speaking, an UnauthorizedAccessException means that the path is a directory, so you can use a System.IO.Path.GetFileName(path) type command and catch the argument exception.

But if you want a more holistic solution, use System.IO.File.GetAccessControl as mentioned by Dale Halliwell

score 0 · Answer 5 · edited May 23 '17 at 11:47

Of course you can check ReadOnly flags using System.IO and probably ACL security on the file combined with the current user too, but like Mehrdad writes in his comment it would never be full-proof in all cases. So you would need exception handling for the exceptional case at all times (even if its just a top-level catch-all, that logs/shows an "unexpected problem" and kills your application).

score 0 · Answer 6 · answered Sep 18 '09 at 12:45

0

You should get the access control list (ACL) of that file.

But this doesn't necessarily mean you could actually delete it because the readonly flag could still be set or another program has locked the file.

answered Sep 18 '09 at 12:45

codymanix

28,510
21
92
151

score 0 · Answer 7 · answered Sep 18 '09 at 12:54

Seems like it would be easier to do things in the order of:

Get whatever information you need about the file in order to do the other parts (delete database data, etc)
Try to delete the file
If you successfully delete the file, then carry out the rest of the "cleanup" work. If you don't successfully delete it, return/handle the exception, etc.

How do I check whether File.Delete() will succeed without trying it, in C#?

7 Answers7

Linked