VFS locking

[starksm64]

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");
 tmpRoot.delete();
 tmpRoot.mkdir();
 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?

[alesj]

This should be removed asap.
Marko?

[mstruk]

I'll look into it over the weekend.

- marko

[alesj]

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. ;-)

[dimitris]

so there is a magic flag, after all?

[anil.saldhana]

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

[mstruk]

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;
 try
 {
 lastModified = conn.getLastModified();
 System.out.println("lastModified, "+lastModified);
 }
 finally
 {
 in.close();
 }

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();
 conn.setUseCaches(false);

 long lastModified = conn.getLastModified();

 conn = null;
 jarFileUrl = null;
 System.gc();
 Thread.sleep(500);
 System.gc();

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

- marko

[starksm64]

"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.