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.
This is caused by the cache reimplementation. It caused a change in the functionality, because Turbo.getCachedMeta(fo) does not consult the disk cache, unlike the old code. We might want to put there Turbo.getMeta(fo), but it must be carefully tested when the refresh is invoked to get the status.
Created attachment 21494 [details] A deadlock that occurs when I replace Turbo.getCachedMeta() with Turbo.getMeta().
The problem with this is, that it's too dangerous (see the attached thread dump).
The problem is, that the requests are comming in AWT thread (isn't this wrong??) and Turbo.getCachedMeta() takes the properties from the memory layer only when called from AWT. It does not consult the disk. The best behavior IMHO would be to check the disk layer and when fprops == null, consider the file as not local.
Fixed in trunk as proposed: /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.325; previous revision: 1.324
Created attachment 21496 [details] The textual patch that fixes this issue.
It was strange that FS code called from AWT did not acccess cache disk level. It's FS anyway so AWT client must count with delays. REVIEWED
Turbo.getCachedMeta() has a condition on AWT thread. That's why. Anyway, thanks for the review, the fix is now merged into release41 branch: /cvs/vcscore/src/org/netbeans/modules/vcscore/VcsFileSystem.java,v <-- VcsFileSystem.java new revision: 1.324.2.1; previous revision: 1.324
Verified.