0

I'm trying to use the following code to delete a read-only file.

var fileInfo = new FileInfo(saveLocation);
fileInfo.IsReadOnly = false;
fileInfo.Delete();

When it gets to the third line, the following exception is thrown

Message: The process cannot access the file '\\filepath\filename.pdf' because it is being used by another process.

Note: \\filepath\filename.pdf is not the actual file path, I'm just using it to replace a longer path

I've checked the file, and before the code runs, it is set to read-only, and after the code runs, it is not anymore.

Am I incorrect in thinking that when a file is opened as read-only it is not considered to by in use? I'm pretty sure that is true for Microsoft office files suck as .xlsx files, but maybe not for PDFs?

Ultimately, my goal is to be able to push an updated version of this file to a shared location even if some user has the file open on their machine, which is why I initially set it to be read-only.

abatishchev
  • 98,240
  • 88
  • 296
  • 433
Eric
  • 688
  • 2
  • 9
  • 23
  • The error message has nothing to do with the file being read-only or not. The file is locked by another process, which is preventing the deletion. Is there something running on your system that may have a lock on that file before you start your program? – Tim Mar 23 '15 at 17:56
  • You can use Process Explorer to see what application has a handle open to that file: https://technet.microsoft.com/en-us/sysinternals/bb896653.aspx (use the binoculars) – Stormenet Mar 23 '15 at 17:56

1 Answers1

1

Message: The process cannot access the file '\filepath\filename.pdf' because it is being used by another process.

This is not the same as the file being read-only.

You can find out in code which process is locking the file

https://stackoverflow.com/a/20623311/141172

You can also find out from the command line

UPDATE

Based on your comments, it seems like you may want an exclusive lock on the file for the duration that you are processing it

open file in exclusive mode in C#

Command-line tool for finding out who is locking a file

Community
  • 1
  • 1
Eric J.
  • 147,927
  • 63
  • 340
  • 553
  • I guess my assumption was that setting the file to read-only would prevent another process from locking the file. Is that not correct? – Eric Mar 23 '15 at 17:59
  • Read only does not prevent another process from locking the file. You want to obtain an exclusive lock if you want to ensure that no other file can obtain at least a read lock on the file. Often read only is more of an FYI than an actual enforcement, because other processes often have permission to change that file attribute (and sometimes will). – Eric J. Mar 23 '15 at 18:00
  • Maybe a topic for a separate question, but is there a way to make a file unlockable? – Eric Mar 23 '15 at 18:02
  • You can prevent *another* process from obtaining any lock by taking an exclusive, share-none lock yourself. I added a link to my answer showing how to do that. I'm not aware of a mechanism to say "nobody can lock this file at all", other than denying permissions to access the file in the first place. – Eric J. Mar 23 '15 at 18:04
  • Thanks. The issue is that the file I am trying to delete would have been created a week in the past, so by the time this code is run, someone else who opened the file during the week and left it open on their computer probably already has a lock. I"ll probably have to approach the problem another way. – Eric Mar 23 '15 at 18:08
  • It may be possible to determine who is locking the file and setup some sort of mechanism to alert them to release the file. Note that you can usually *copy* a locked file. You could try your method, and if that fails 1) Perform a copy instead, 2) Place the original file in a list of files to be deleted later, 3) Periodically attempt to delete files from that list. – Eric J. Mar 23 '15 at 18:38
  • My solution is to save versions of the file to the historical directory, and in the main directory where users will go to access the file, I am going to have a shortcut pointing to the latest version of the file. I was saving historical versions anyway, so this is a convenient approach for me. – Eric Mar 23 '15 at 18:53