Microsoft Developer Network > Forums Home > Visual C# Forums > Visual C# General > How to Unlock a file used by other Process?

Answered How to Unlock a file used by other Process?

  • Tuesday, August 14, 2007 8:08 PM
     
     
    Hi Guys,

    Is there a way to unlock a file used by other Process. I have installed this Unlocker Utility that does the job nicesly.
    But i wanted to create my own utility like this in C#. Point in the right direction will also helpfule in this case.

    http://ccollomb.free.fr/unlocker/

    Thanks for your help in Advance....

Answers

All Replies

  • Tuesday, August 14, 2007 8:36 PM
    Moderator
     
     
    It's not safe to unlock a file used by another process, if it's used by another process it's likely writing to the file.  If you unlock the file it will likely corrupt the data.

     

  • Wednesday, August 15, 2007 7:43 PM
    Moderator
     
     Answered
    If this is a process which you have the code, then open the file without locking it.
  • Friday, August 17, 2007 4:36 AM
    Moderator
     
     Answered

    To add some words:

    You may first to kill the process who use the file first.

    Check a Task Manger wrote in C# (mainly use System.Diagnostics.Process class): http://www.codeproject.com/csharp/mytaskmanager.asp

     

    Thanks

  • Tuesday, August 21, 2007 9:06 AM
     
     

    Hi,

     

    In order to unlock a file used by another process you should run code in the context of that process and do a CloseHandle on the specific handle.


    You could take a look at CreateRemoteThread function in order to run code in the context of another process.

     

    Try to check out this article - http://blogs.msdn.com/jmstall/archive/2006/09/28/managed-create-remote-thread.aspx for reference.

     

    Citizens on the earth

     

     

     

     

     

     

     

  • Tuesday, August 21, 2007 11:48 AM
    Moderator
     
     
     Citizen on the earth wrote:

    Hi,

     

    In order to unlock a file used by another process you should run code in the context of that process and do a CloseHandle on the specific handle.


    You could take a look at CreateRemoteThread function in order to run code in the context of another process.

     

    Try to check out this article - http://blogs.msdn.com/jmstall/archive/2006/09/28/managed-create-remote-thread.aspx for reference.

     

    Citizens on the earth

     

    What do you think the other application is going to do when it tries to use that now closed handle?  It's going to crash.  And if that application was writing to the file (which is said it was going to do by opening the file in that way) when you close the file handle, the file will now be corrupt.

     

  • Wednesday, August 22, 2007 7:36 AM
     
     

    Thanks very much for your kind reminder. I should have mentioned that the CreateRemoteThread approach is dangerous, as the blog(http://blogs.msdn.com/jmstall/archive/2006/09/28/managed-create-remote-thread.aspx) did.

     

    There is a potential danger to run code in the context of another process using CreateRemoteThread function indeed.

     

    There is already a disclaimer in this blog- http://blogs.msdn.com/jmstall/archive/2006/09/28/managed-create-remote-thread.aspx saying "CreateRemoteThread is evil, could dead-lock, doesn't always work (particularly across-sessions), and should be avoided in favor or friendlier inter-process communication libraries unless you're a rocket scientist.".

     

    Frankly speaking, we are not allowed to access a file which is used by another process in most cases.

     

    If the original poster tries to unlock a locked file, maybe this is a workaround, but we must wake up to this risk in using it.

     

    Citizens on the earth  

     

  • Tuesday, March 25, 2008 1:45 PM
     
     

    It's not always true that unlocking a file will likely corrupt data - you do on occasions have to deal with badly written apps that hold unnecesary locks. One such that is causing me grief is Adobe Viewer, which apparently locks a file for as long as you are viewing it (Why???).

     

    I too would like a solution to the original poster's problem of unlocking a file that was locked by another process. Clearly it's possible because the unlocker utility can do it.  But how???? I'm guessing there must be some relevent unmanaged API functions?

     

    In my case I have a Windows Forms app which features a web browser control that can be used to view PDFs (by navigating to them; internally the browser control, via IE, invokes Adobe viewer). For some reason, on occasions, Adobe viewer remains open even after the browser control has been closed so the PDF remains locked, which wrecks havoc if the user later asks my app to view or delete that PDF.  (Yes, I know I should look at the cause: Why Adobe viewer isn't being shut down, but that's complicated and I'm not convinced it's even within the control of any code I have access to. Just forcibly removing any lock on the PDF would be a lot simpler).

  • Tuesday, March 25, 2008 1:53 PM
    Moderator
     
     
     Simon Robinson wrote:

    It's not always true that unlocking a file will likely corrupt data - you do on occasions have to deal with badly written apps that hold unnecesary locks. One such that is causing me grief is Adobe Viewer, which apparently locks a file for as long as you are viewing it (Why???).

    There's many reasons why an application locks a file.  One is that it is writing to the file; so, unlocking it and writing to it from another thread/process will corrupt the file.  Two is that it will write to the file; so, unlocking it and writing to it from another thread/process will randomly corrupt the file. Three, the application simply can't handle changes to the file while it's reading it; for whatever reasons. Four, true, the application isn't written correctly--in which case contacting the vendor would be the best course of action.

     

    But, you can't tell why--that's an implementation detail of the application.  You can observer one instance where it doesn't write to the file and assume that it will do that every single time; but if you're wrong you end up corrupting the file.

  • Tuesday, May 06, 2008 5:28 PM
     
     

    Hi Simon,

     

    Have you found any work arounds to your Adobe issue? I'm running into the same exact problem.

     

    Thanks,

    Mike

  • Wednesday, June 11, 2008 4:26 PM
     
     
    He's not asking for political commentary.  He is simply asking for a technical solution.  I don't understand how this can be the answer.  It doesn't help with the problem at hand.  
  • Wednesday, October 22, 2008 5:34 PM
     
     Proposed Answer

    I'm glad someone finally said something. If someone asks a technical question how about answering or asking for clarification

    BTW....I'm looking for an answer to the OP's question as well.

  • Monday, January 25, 2010 5:03 PM
     
     

    I'd like to add to this. First off, I need this solution myself, and I should have ~~remembered~~ the CreateRemoteThread. Between things I have done to determine which process(es) have a module/file/handle opened, and killing external process, I'm flaberghasted I forgot.

    The CreateRemoteThread is indeed a way to go. Using things like CreateToolhelp32Snapshot, one can find any/all processes that have a file opened.

    Now for justification of why people need the ability to close file locks, and not just kill the process.

    Emergencies.

    Lets say we have a process that locks a file that it should be able to lock. And lets say this process is 100% good. And it will clean up the lock, when it is done.

    But then some emergency occurs, like the power of the computer about to fail.
    And lets say, that our business rules (BR) require that we must try to backup that file ASAP, to ensure it is fresh and up to date as best as possible.

    In this situation, the quickest way to save the file, is use something like CreateRemotethread on the process with the lock, suspend all other threads in that process, and let the psuedo thread close the handle. After that, it does not matter to our BR's, what the original process would do, is-doing, with that handle. We accomplished our BR's.

    In my case, we have processes we make that will lock files for various reasons. And they are huge and they get used by other processes, which are beyond our control. Under normal circumstances, our processes clean up the files when done. But because we interact with other processes that may lock our files, we are left with 3 decisions:

    1) Let the huge files stack till we are out of disk space.
    2) Kill the processes. Then cleanup our files.
    3) Try to remove the file locks. Then cleanup our files.

    In the scheme of things, it would be better to remove the lock, and let the offending processes deal with bad file handles, than to just arbitrarily kill the process. Put another way, killing a process may affect many more things than just one file you want a lock removed from, versus unlocking that one lock.

     

  • Tuesday, April 20, 2010 5:46 PM
     
     

    hi

    In C#, if 2 processes are reading and writing to the same pdf file, what is the best way to avoid process locking exceptions? - I am using itextsharp

    The below is the code

      using (Stream inputPdfStream = new FileStream(@"C:\AERShare\Variables.pdf", FileMode.Open, FileAccess.Read, FileShare.Read))
            using (Stream inputImageStream = new FileStream(@"C:\AERShare\"+strName+".jpg", FileMode.Open, FileAccess.Read, FileShare.Read))
            using (Stream outputPdfStream = new FileStream(@"C:\AERShare\result.pdf", FileMode.Create, FileAccess.Write, FileShare.None))
            {
                var reader = new PdfReader(inputPdfStream);
                var stamper = new PdfStamper(reader, outputPdfStream);
                var pdfContentByte = stamper.GetOverContent(1);

                iTextSharp.text.Image image = iTextSharp.text.Image.GetInstance(inputImageStream);
                image.SetAbsolutePosition(100, 100);           
                pdfContentByte.AddImage(image);
                stamper.Close();
            }

    The above code is working fine but it creates new pdf file . But i want write to same existing pdf file

    It through's a below exception

    system.io.ioexception the process cannot access because it is being used by othe file .

    Can anyone guide me ?

    Thanks,

    Steed.