This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
I've noticed a few commit validation tests passing on other platforms but failing on mac os - I went so far as to tar up the exact bits that failed on my mac and untar them on linux where the tests passed. Possibly of interest that mac is identifiably a unix with / as the path separator, but HFS is case preserving but not case sensitive?
Created attachment 14628 [details] test results
Created attachment 14629 [details] more test results
Re. TestUtilTest.testCreateFileFromContent - note that this is not a test of IDE functionality, it is just testing that the test suite's helper class is functioning enough for the tests to be meaningful. Try changing the constant 1500 (milliseconds) to something a bit larger and see if that works. All I'm trying to do is make sure writing a file changes its timestamp. The GlobFileBuiltQueryTest failures seem to be exactly the same issue. See if a longer pause fixes the problem. Maybe HFS has extremely poor timestamp granularity? Or maybe Thread.sleep doesn't actually sleep? I can't investigate it myself for obvious reasons; maybe this is enough of a hint for you to find the problem.
I tried raising the timeouts to 15000ms, and the tests fail just the same, so I'm guessing the problem is somewhere in filesystems. I wrote a small app to test the timestamp granularity of HFS, and it is 1000ms and reports the correct results when using java.io.File. Radek, maybe you could take a look at this on my Mac sometime during the week?
Created attachment 14720 [details] Please try additional asserts - maybe it could help
With the patch, got the following failures: testCreateFileFromContent: junit.framework.AssertionFailedError: touched and changed timestamp at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at org.netbeans.api.project.TestUtilTest.testCreateFileFromContent(TestUtilTest.java: 67) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.netbeans.junit.NbTestCase.run(NbTestCase.java:119) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:173) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:129) at org.netbeans.xtest.plugin.jvm.JUnitTestRunnerLauncher.main(JUnitTestRunnerLauncher.jav a:41) testTimTime: junit.framework.AssertionFailedError at junit.framework.Assert.fail(Assert.java:47) at junit.framework.Assert.assertTrue(Assert.java:20) at junit.framework.Assert.assertTrue(Assert.java:27) at org.netbeans.api.project.TestUtilTest.testTimTime(TestUtilTest.java:84) at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) at java.lang.reflect.Method.invoke(Method.java:324) at junit.framework.TestCase.runTest(TestCase.java:154) at junit.framework.TestCase.runBare(TestCase.java:127) at junit.framework.TestResult$1.protect(TestResult.java:106) at junit.framework.TestResult.runProtected(TestResult.java:124) at junit.framework.TestResult.run(TestResult.java:109) at junit.framework.TestCase.run(TestCase.java:118) at org.netbeans.junit.NbTestCase.run(NbTestCase.java:119) at junit.framework.TestSuite.runTest(TestSuite.java:208) at junit.framework.TestSuite.run(TestSuite.java:203) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:173) at org.netbeans.xtest.testrunner.JUnitTestRunner.runTests(JUnitTestRunner.java:129) at org.netbeans.xtest.plugin.jvm.JUnitTestRunnerLauncher.main(JUnitTestRunnerLauncher.jav a:41)
Seems to have stopped failing. May be upgrade to 1.4.2 DP 3 on mac, or maybe something changed in the test.
GlobFileBuiltQueryTest is now passing for you? Note that I suppressed the failing tests in the XTest test config, so they will be run only if you run e.g. ant/project/build.xml#test (Alt-F6 in the IDE). They are not run during commit validation etc.
Ah...well, then, will reopen - I had assumed it was still in commit validation
Okay, Radek and I just looked at this, and the problem is this: On the mac, if you simply open an output stream over a file and close it, the java.io.File's lastModified date does not change - you cannot use that technique to touch a file on the mac. So, open questions: - Is this a bug that should be filed with Apple? (I imagine not) - More importantly, do we have anything in NetBeans that depends on this technique for changing the timestamp of files, because it's not going to work on the mac - What to do with this test to make it either pass or be ignored?
Back to you, Jesse - we should find some way to make the test not fail on the mac (probably just Utilities.getOS() == Utilities.OS_MAC, and if so, actually write some content). Attach patches if you want me to test something.
"On the mac, if you simply open an output stream over a file and close it, the java.io.File's lastModified date does not change" - umm. Strange indeed (especially for an OS based on Unix). Does it correctly truncate the file to length 0? If you write content to the output stream before closing it, does it then change the modification time? Does the same thing happen using other tools on Mac OS X, e.g. Perl (perl -e 'open FOO, ">foo.txt"; close FOO')? Does calling FileOutputStream.flush() before closing make any difference? Temporarily reassigning to Tim until I can get info on these things.
Okay, I think I've got it. The file behaves as you would expect, with a single exception: If it is 0 bytes before the stream is opened, and nothing is written, the timestamp doesn't change. The following code produces the output below: File f = new File ("/test"); long t = f.lastModified(); System.err.println("Last modified " + t); FileOutputStream fos = new FileOutputStream (f); Thread.currentThread().sleep (3000); // fos.flush(); // fos.close(); long t2 = f.lastModified(); System.err.println("Last modified now: " + t2); System.err.println("----------"); f = new File ("/test2"); if (f.exists()) { f.delete(); } fos = new FileOutputStream (f); fos.write("Hello world".getBytes()); fos.close(); t = f.lastModified(); System.err.println("Last modified " + t); Thread.currentThread().sleep (3000); fos = new FileOutputStream (f); fos.close(); System.err.println("File exists: " + f.exists()); Thread.currentThread().sleep (3000); long t3 = f.lastModified(); System.err.println("Last modified now: " + t3); First run with files pre-created via "echo hello > /test", "echo hello > /test2" - both have content: Last modified 1091216655000 Last modified now: 1091216662000 ---------- Last modified 1091216665000 File exists: true Last modified now: 1091216668000 The content is removed, and the timestamp is updated. Subsequent run - file "test" is now a 0 byte file after the previous run's write: Last modified 1091216662000 Last modified now: 1091216662000 ---------- Last modified 1091216762000 File exists: true Last modified now: 1091216765000 So that's the problem. What do you think - file a bug for Apple, or this is reasonable behavior?
IMHO this is a bug in Mac OS X or its JRE implementation and should be filed as such. Reassigning to Filesystems since we should be able to work around this bug. For example: LocalFileSystem.outputStream on Macs can check to see if the file is currently empty. If so, return a special proxy OutputStream which checks to see if any bytes are written to it. If close() is called and no bytes have been written, the proxy OS should call file.setLastModified(System.currentTimeMillis()).
Filed Apple Radar 3746997
Created attachment 16612 [details] Please test on mac.
Please test attached diff.
Where has the actual test that should fail gone? It seems like some things have been moved around - I installed the patch but couldn't actually find the test to run.
ant/project/test/unit/src/org/netbeans/spi/project/support/ant/GlobFileBuiltQueryTest.java Currently passing for me on Linux but excluded from commit validation.
reasigning
with the patch applied the test passed, without the patch it failed.
Workarounded: /cvs/openide/src/org/openide/filesystems/LocalFileSystem.java new revision: 1.65; previous revision: 1.64 Please, close if its OK.
fixed now, test passes in today's daily build
Cool, thanks for your help everybody.
Said to no longer be an issue on Mac Tiger. Can anyone confirm? If so, can we remove any obsolete workarounds for the issue?
This issue was solved long time ago. Because nobody has reopened it neither added comments, we are verifying/closing it now. If you are still able to reproduce the problem, please reopen. Thanks in advance.