Ticket #1635 (closed defect: fixed)
Opened 2013-01-23T16:07:33-06:00
Last modified 2013-05-31T16:05:13-05:00
UpdaterTest unit tests fail, Windows
| Reported by: | aivar | Owned by: | dscho |
|---|---|---|---|
| Priority: | major | Milestone: |
|
| Component: | Updater | Version: | |
| Severity: | serious | Keywords: | |
| Cc: | Blocked By: | ||
| Blocking: | #1901 |
Description
I'm trying to build ImageJ2 in NetBeans, Windows 8 64-bit. I patched some errors in ClassUtilsTest, AppUtilsTest, and FileUtilsTest (see 'windows' branch.) However now I'm getting 15 failures 1 error from 30 tests in UpdaterTest.
Attachments
Change History
Changed 2013-01-23T16:08:10-06:00 by aivar
- attachment UpdaterTest.txt added
comment:1 Changed 2013-01-23T16:13:48-06:00 by aivar
The most worrisome thing I am seeing is that things like "assertTrue(new File(ijRoot, "jars/egads-0.1.jar").delete());" are failing. For some reason files are not being deleted immediately. A poor workaround would be to use "deleteOnExit()".
comment:2 Changed 2013-01-23T18:22:55-06:00 by aivar
Possibly related:
http://stackoverflow.com/questions/8097067/java-6-file-deletion
http://stackoverflow.com/questions/991489/i-cant-delete-a-file-in-java
A much-simplified version succeeds in the assertion:
"
final File tmp = File.createTempFile("tmp", ".txt");
final FileOutputStream out = new FileOutputStream(tmp);
out.close();
assertTrue(tmp.delete);
"
comment:3 Changed 2013-01-28T16:00:35-06:00 by aivar
Same issues happen in a Windows 7 VM. Generally related to the discussion at:
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4722539 "File.delete() doesn't work the same between Windows & Unix"
"We cannot fix this, for the same reasons that we cannot fix 4045014: There's no
efficient way to force Windows-style semantics on Unix, and vice-versa. This
difference is annoying, but it's not a violation of WORA because the
specification doesn't make any guarantees about what happens when you delete an
open file."
Windows won't delete files with an open handle and it won't delete a file that doesn't exist.
Some say the Java 7 NIO.2 classes offer improved file deletion.
comment:4 Changed 2013-01-28T16:09:20-06:00 by dscho
So is the file still in use? Then this is the bug.
comment:5 Changed 2013-01-28T16:35:37-06:00 by aivar
Yes. The platform-specific issue is that Windows is more rigorous about locking files.
comment:6 Changed 2013-01-28T16:35:56-06:00 by aivar
Another platform-specific issue:
Under Windows 'assertTrue(new File(ijRoot, "blah").delete());', where "blah" is a new file name, fails; under OS X this succeeds.
Workaround for Windows is:
File blah = new File(ijRoot, "blah");
if (blah.exists) {
assertTrue(blah.delete());
}
comment:7 Changed 2013-01-28T16:42:58-06:00 by dscho
As to the locking: have you identified which files are still locked? We should get them unlocked before deleting them.
As to the deleting non-existent files: have you identified which files those are? We should not try to delete them.
comment:8 Changed 2013-01-29T13:25:03-06:00 by aivar
- Summary changed from UpdaterTest unit tests fail, Windows 8 to UpdaterTest unit tests fail, Windows
comment:9 Changed 2013-01-29T13:27:20-06:00 by aivar
Locking was due to not explicitly closing JarFiles. They would get closed in the finalizer.
The "deleting non-existent files" issue doesn't actually happen in the build; it's just something else I came upon while debugging and thought I'd preserve a note here.
comment:10 Changed 2013-03-19T11:25:07-05:00 by bdezonia
- Status changed from new to reviewing
dscho, please associated with some feature ticket
comment:12 Changed 2013-03-22T15:41:16-05:00 by dscho
aivar, can you make your changes available as a pull request that merges cleanly with 'master', please? Otherwise I'll be forced to redo the fixes and retroactively waste the work hours you spent on this issue.
comment:13 Changed 2013-04-09T18:08:20-05:00 by dscho
- Status changed from reviewing to closed
- Resolution set to fixed
Fixed it myself in aad7221b38a588da809325adebff15f39f399412.
Test results