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.
050106 custom, JDK 1.6. Thrown every time I try to click on a hyperlink in the output window from an Ant build. (Links to files in a CVS working dir of Apache Ant.)
Created attachment 19538 [details] Stack traces
It looks like the call goes to wrong RepositoryFiles, but they are initialized with the parent FO, so it should be correct. Jesse, can you please provide the content of /space/src/ant/src/main/org/apache/tools/ant/CVS/Entries file? Isn't it there an "ant" folder by a mistake? But then it would be in RepositoryFiles... no idea where the "ant" folder came from...
Jesse, In which repository is the "ant/src/main/org/apache/tools/ant" folder? Is it possible, that there is an empty subfolder "ant" on the server, which was checked out, but then pruned by update -P ?
I've checked out "ant" module from :pserver:anoncvs@cvs.apache.org:/home/cvspublic But there is no "ant/src/main/org/apache/tools/ant/ant" folder. So the presence of the nested "ant" remains a mystery to me. Petr, do you have any idea what can be wrong?
findResource() found it. And it's virtual one. And probably cached by ASF because it's not in VFS structures anymore. Anyway it's probably too late. As Martin pointed out main problem is that ant/ant has ever appeared. My tip is that we either incorrectly handle LIST command output or the output contains inconsistencies. With 100% reprocase & debugger should be peace of cake. Also was it build-in CVS or cmdline one?
I can not find 100% reproducible steps. It has happened to me once when I removed one file both from the disc (/bin/rm) and from CVS/Entries - that simulates an external cvs rm -f + cvs ci. When I returned to the IDE the same assertion error was thrown (once). However, further attempts to reproduce it were not successful, probably also due to auto-refresh when the IDE gets focus. Jesse, do you have reliable steps how to reproduce this?
It can be that this issue is caused by the discrepancy between actual content of CVS/Entries and the memory-cached content in RepositoryFiles. The cache just does not count with the fact, that the data stored on disk change without an explicit write from memory. Using CVS/Entries that live it's own life seems to be dangerous. But that still does not explain the ant/ant problem.
The discepancy you describe cannot raise this assert. It's reverse problem, an information about fileobject is missing in RepositoryFiles but the fileobject exists. VFS constructs fileobjects by listing disk and adding content of RepositoryFiles. The same VFS is caught here to resolve folder flag but is cannot find the fileobject neither on disk nor in RepositoryFiles. There are RepositoryFiles.removeFileObject() calls in TU.pC() that does not trigger atomic VFS children refreshing. It creates temporary inconsistency that can raise the assert.
Internal inconsistency FIXED in: VcsFileSystem.java new revision: 1.304 RepositoryFiles.java new revision: 1.3
Let me know if you still need any info from me. I don't think I have anything strange going on; just a plain NB checkout (-P always), which I usually work on from the command line, but also have represented in the IDE mostly for viewing version info.
Sorry folks, not fixed in the current dev build (confirmed that I have the new RepositoryFiles.java).
Created attachment 19590 [details] Recent stack traces
Sorry, Apache Ant checkout, not NB checkout.
So I deleted every .nbintdb and CVS/netbeans.cmd.cache I had on disk and restarted the IDE; the problem remains when I try to browse Ant sources. What is suspicious is this: AbstractFileObject@15c0729[file:/space/src/ant/src/main/org/apache/tools/ant/]/ant The root of the WD is /space/src/ant; the relative path to the main package is src/main/org/apache/tools/ant/. Perhaps VCS is getting confused by the repeat of the name "ant"?
Created attachment 19591 [details] ZIP of interesting CVS metadata dirs
I have looked at attachements and have not discovered any suspicity. I tried 3 times checkout and cannot reproduce. The assert is wrong. At least it's wrong in case when an external program removes a file and it's not catched by VFS. The VFS assumtion that nonexiting disk file was before reported as a virtual is broken. Here I cannot find empty ant/ant that would explain external change (pruning ant), however.
But I checked out from /home/cvspublic. Your CVS/Root points to /home/cvs and does *not* contain connection method.
Wrong assert removed. Leaving trace in log that a file was probably externaly removed and will by invalidated. This fix somehow hides ant/ant mystery, relaxing it. External inconsistency FIXED in: VcsFileSystem.java new revision: 1.305 RepositoryFiles.java new revision: 1.4
Since I am an Ant committer, my CVS/Root does indeed use a special syntax (since it is an SSH extension). I will check in a new dev build to see if everything is OK.
Assertion is indeed gone, but now there is issue #53453 which is just as bad.
Haven't seen any problems in a while.