10 Replies Latest reply on Aug 24, 2007 12:23 AM by EJP

    File locking issue

    807605
      hi ,

      I use a java applet for ftp images upload using a third party ftp API library (edtftpj).
      i run my applet from browser but I'm experiencing a strange issue :
      -i upload a file & leave the browser opened.
      -i then open this same file with gimp or photo-shop & get 'file in use' error.
      -if i close browser & try opening file ,the file is opened correctly.

      I investigated the issue more thoroughly and here are my conclusions :

      1) First i made sure to close all File's streams in the applet.so I'm sure i eliminated this issue of forgotten opened file streams .
      2) also i made sure to close all network connections that might be holding the File lock.

      It's clear that another process is still locking the File & preventing access to it.
      i used a win32 program (procExp) to monitor active processes . it turned out that javaw.exe is the process that use the File. i was convinced of this fact with a simple experiment : if i destroy the applet (closing applet's browser window -not necessarily all browser instances-) then in this case the file lock is released and i can access and delete File correctly.

      my questions :
      -How to instruct javaw.exe to release the File lock ? (is that possible at all to do ?)
      -is it a bug in JVM ? (i'm using jdk1.4.2)
      -or is it an OS centric issue related to windows only ?

      i would appreciate your ideas about this problem .

      thanks.
        • 1. Re: File locking issue
          EJP
          First i made sure to close all File's streams in the applet.so I'm sure i eliminated this issue of forgotten opened file streams .
          Double-check this. Make sure all execution paths are covered, i.e. close the streams in a 'finally' block. Post your code here for review. if necessary.
          2) also i made sure to close all network connections that might be holding the File lock.
          Network connections don't hold file locks.
          • 2. Re: File locking issue
            807605
            First i made sure to close all File's streams in
            the applet.so I'm sure i eliminated this issue of
            forgotten opened file streams .

            Double-check this. Make sure all execution paths are
            covered, i.e. close the streams in a 'finally' block.
            Post your code here for review. if necessary.
            2) also i made sure to close all network
            connections that might be holding the File lock.

            Network connections don't hold file locks.
            thanks for replying.

            for streams closing : i don't open any streams in my code.I'm only using ftp methods like FTPClient.get() & FTPClient.put().
            these ftp methods release the File when the ftp transfer is complete.i checked that . i also force the ftp connection to quit /close .but still same issue : can't access File used in applet .

            any ideas ?

            thanks.
            • 3. Re: File locking issue
              807605
              Looking at the source code for FTPClient, it looks like when you call put() using Strings for the filenames it does not close the InputStream for the file.

              Try using the version of put() which accepts your own InputStream representing the file, then close it manually in a finally block when it's done.
              • 4. Re: File locking issue
                807605
                Looking at the source code for FTPClient, it looks
                like when you call put() using Strings for the
                filenames it does not close the InputStream for the
                file.

                Try using the version of put() which accepts your own
                InputStream representing the file, then close it
                manually in a finally block when it's done.
                Thanks
                even though i was almost sure this is not the cause of issue , i tried using InputStream instead of String in put() & get ftp methods.made sure to close them in finally catch block .but still same problem!

                I'm still believing that javaw.exe process is responsible for locking the file .i know this seems odd .I'm really experiencing hard times to figure out this problem.

                can you help guys ? i would appreciate it a lot.
                • 5. Re: File locking issue
                  807605
                  Hi,
                  let me explain more the situation in the applet :

                  if i cancel a ftp upload i can delete the partially uploaded file .(indeed i had to quit() & reconnect before being able to delete ftp file).

                  however i'm facing a hard time to do same with file download:
                  if i cancel ftp download & try to delete partial file on local drive the File.delete() method fails.
                  it seems some other process (maybe javaw.exe or the Thread i use for download) is locking the file.
                  before calling File.delete() i call Thread.interrupt() to stop download thread. i also set my thread object to null and call System.gc() before trying delete() .but still unable to delete the partial downloaded file.

                  any Ideas ? thanks.
                  • 6. Re: File locking issue
                    807605
                    Here's a long shot: as a test in your applet, comment out the FTP calls, open up a file into a FileInputStream, then close it straight away. See if the file is locked. If the file is not locked, then we can assume the problem is within the FTP library you are using. In which case, you're out of luck and might consider using another library instead.
                    • 7. Re: File locking issue
                      807605
                      Here's a long shot: as a test in your applet, comment
                      out the FTP calls, open up a file into a
                      FileInputStream, then close it straight away. See if
                      the file is locked. If the file is not locked, then
                      we can assume the problem is within the FTP library
                      you are using. In which case, you're out of luck and
                      might consider using another library instead.
                      I was able to figure out the problem :

                      the ftp transfer is triggered in a java Thread. to stop (pause) or kill the thread i was using the Thread.interrupt() method.it turns out this method call does stop the thread but unfortunately it doesn't release resources used by the thread (Files in my case).
                      the solution was to use a flag to stop and pause the thread and remove the Thread.interrupt() & Thread.suspend() methods.

                      i wouldn't advise anyone to use theses Thread methods above because they are unreliable for releasing resources after killing the Thread.
                      • 8. Re: File locking issue
                        EJP
                        Why would Thread.stop() release resources if Thread.interrupt() doesn't?
                        • 9. Re: File locking issue
                          807605
                          Why would Thread.stop() release resources if
                          Thread.interrupt() doesn't?
                          One change that has been made in Java 2 to reduce the possibility of deadlock is the deprecation of Thread�s stop( ), suspend( ), resume( ), and destroy( ) methods.

                          The reason that the stop( ) method is deprecated is because it doesn�t release the locks that the thread has acquired, and if the objects are in an inconsistent state (�damaged�) other threads can view and modify them in that state. The resulting problems can be subtle and difficult to detect. Instead of using stop( ), you should use a flag to tell the thread when to terminate itself by exiting its run( ) method.
                          • 10. Re: File locking issue
                            EJP
                            Exactly, and I've been aware of all that since about 1997. I don't know whether that was supposed to answer my question to you as the OP but it doesn't.

                            Sadly I misread your second-last post to say that you are using Thread.stop(), which you're not, so that explains some of the confusion. But I don't understand why you say Thread.interrupt() doesn't release the resources. It isn't supposed to. It doesn't do anything except set a flag and cause your thread to throw an InterruptedException if it's calling Object.wait(), Thread.sleep(), or certain I/O routines. It's up to your thread to react appropriately, and/or to call Thread.isInterrupted at appropriate intervals.

                            So Thread.interrupt() (a) provides the boolean flag you need and (b) also interrupts your thread under some circumstances. So it is definitely the solution you should be using: call Thread.interrupt() to tell the thread to exit, and call Thread.isInterrupted() in the thread itself to know whether to do so.