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.

Bug 58663 - Deletion of files on SFS not reliably detected if changes come from disk
Summary: Deletion of files on SFS not reliably detected if changes come from disk
Alias: None
Product: platform
Classification: Unclassified
Component: Filesystems (show other bugs)
Version: 5.x
Hardware: All All
: P4 blocker (vote)
Assignee: Jiri Skrivanek
Depends on:
Blocks: 20323
  Show dependency tree
Reported: 2005-05-06 20:55 UTC by Jesse Glick
Modified: 2009-02-19 22:53 UTC (History)
1 user (show)

See Also:
Issue Type: DEFECT
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description Jesse Glick 2005-05-06 20:55:51 UTC
Steps to reproduce:

1. Start with a clean-built NB source tree.

2. Run

ant -f apisupport/build.xml
ant -f apisupport/lite/build.xml
ant -f utilities/group/build.xml
ant -f sysprops/build.xml

3. Run

ant -f nbbuild/build.xml tryme

4. Make sure Favorites and Runtime tabs are both displayed.

5. Add to Favorites tab: nbbuild/netbeans

6. Browse to extra/config/Modules dir. You should see four XML files incl.

7. The Runtime tab should be showing System Properties and also Bean Browser.

8. Expand Bean Browser -> Root of system filesystem -> Modules dir. You should
see org-netbeans-modules-sysprops.xml among many others.

9. Run:

ant -f sysprops/build.xml clean

10. Switch back to the IDE.

11. org-netbeans-modules-sysprops.xml has disappeared from Favorites as expected.

12. BUT it has not disappeared from the system filesystem as shown in Runtime.
No change in the Runtime tab observed. (Expected:
org-netbeans-modules-sysprops.xml disappears from SFS in Runtime; status bar
shows System Properties module being disabled; System Properties node disappears
from Runtime tab.)

13. Right-click Modules in SFS in Runtime and choose Refresh Folder. Now the
expected changes occur.
Comment 1 rmatous 2006-11-20 14:42:31 UTC
Yes, there is invoked refresh on MasterFS after invoking ant script(BridgeImpl)
but there is no refresh on SFS. As soon as you invoke it explicitly then
everything is OK. 

Either SFS can listen on MasterFS, filter events and refresh itself eventually
or BridgeImpl and other pieces of code must call refresh not only on MasterFS
but also on SFS.

Comment 2 Jesse Glick 2006-11-20 18:04:17 UTC
Should probably be handled by a general refresh API. I thought there was an RFE
filed for a single method call that Ant and other modules could call to trigger
a general system refresh, but now I cannot find it.
Comment 3 Antonin Nebuzelsky 2008-04-15 17:18:33 UTC
Reassigning to new module owner jskrivanek.
Comment 4 Jiri Skrivanek 2008-09-03 13:58:54 UTC
Is this issue still valid? The original use case is obsolete now.
Comment 5 Jesse Glick 2008-09-06 17:28:50 UTC
I don't believe the use case is obsolete. Nothing significant has changed since this was filed AFAIK. It is not a major
use case, of course, but there are various miscellaneous situations encountered in module development where you would
run into this bug.

I could rephrase the request as follows: FileUtil.refreshAll() ought to refresh the SFS in case there have been changes
on disk in the $userdir/config/ layer.
Comment 6 Jiri Skrivanek 2008-11-19 12:10:36 UTC
Fixed. SFS refresh in FileUtil.refreshAll().
Comment 7 Jesse Glick 2008-11-20 04:36:02 UTC
I think I recall that Wade was actually encountering this recently, trying to set keymaps in the userdir and expecting
them to be honored immediately in the running app.
Comment 8 Quality Engineering 2008-11-20 04:44:09 UTC
Integrated into 'main-golden', will be available in build *200811200201* on (upload may still be in progress)
User: Jiri Skrivanek <>
Log: #58663 - refresh default filesystem to reflect possible changes on disk in the $userdir/config.