7 Replies Latest reply on Jun 30, 2008 3:54 PM by Scott Stark

    VFS locking

    Scott Stark Master

      Related to the profileservice tests on win32, I started adding an hdscanner/profileservice repository mock up. However, I see that there are some tests that don't validate file deletion when run on win32, for example this FileVFSUnitTestCase test where the assertion is 'tmp.delete() || isWindowsOS()':

       public void testFileExists()
       throws Exception
       File tmpRoot = File.createTempFile("vfs", ".root");
       File tmp = File.createTempFile("testFileExists", null, tmpRoot);
       log.info("+++ testFileExists, tmp="+tmp.getCanonicalPath());
       URL rootURL = tmpRoot.toURL();
       VFS vfs = VFS.getVFS(rootURL);
       VirtualFile tmpVF = vfs.findChild(tmp.getName());
       assertTrue(tmpVF.getPathName()+".exists()", tmpVF.exists());
       assertTrue("tmp.delete()", tmp.delete() || isWindowsOS());
       assertFalse(tmpVF.getPathName()+".exists()", tmpVF.exists() && isWindowsOS() == false);
       assertTrue(tmpRoot+".delete()", tmpRoot.delete() || isWindowsOS());

      What is the point of not checking the delete return value under win32?

        • 1. Re: VFS locking
          Ales Justin Master

          This should be removed asap.

          • 2. Re: VFS locking
            Marko Strukelj Master

            I'll look into it over the weekend.

            - marko

            • 3. Re: VFS locking
              Ales Justin Master

              I found this comment in some decent non-JBoss code:

               * This implementation opens an InputStream for the given URL.
               * It sets the "UseCaches" flag to <code>false</code>,
               * mainly to avoid jar file locking on Windows.

              See last line. ;-)

              • 4. Re: VFS locking
                Dimitris Andreadis Master

                so there is a magic flag, after all?

                • 5. Re: VFS locking
                  Anil Saldanha Master

                  The best flag is get off Windows. Unfortunately, not a solution for many. :)

                  • 6. Re: VFS locking
                    Marko Strukelj Master


                    so there is a magic flag, after all?

                    There is a flag, but it's not magic :)

                    I've spent a lot of time on this lately.

                    A general rule that works for file: urls (but not for jar:file: urls) is the following:

                     URLConnection conn = fileUrl.openConnection();
                     InputStream in = conn.getInputStream();
                     long lastModified;
                     lastModified = conn.getLastModified();
                     System.out.println("lastModified, "+lastModified);

                    It's getting and closing the InputStream that does the trick.

                    For jar:file: urls I could only achieve file lock release by triggering finalizers - which means it's pretty useless for anything but tests maybe:

                     URLConnection conn = jarFileUrl.openConnection();
                     long lastModified = conn.getLastModified();
                     conn = null;
                     jarFileUrl = null;

                    In this case I'd say the problem is more with JDK implementation than Windows :)

                    - marko

                    • 7. Re: VFS locking
                      Scott Stark Master


                      "mstruk" wrote:

                      In this case I'd say the problem is more with JDK implementation than Windows :)

                      Which is why we want to move away from the jdk url handler reliance. Its a poor api and has unreliable behavior across platforms. All of the jar/zip file behaviors ultimately rely on native code as well.