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.
[dev aug 17] ModuleList sometimes receives more file events than it ought to. For example, after disabling a module (e.g. RMI) via the GUI, which causes the module system to rewrite its XML on disk (e.g. Modules/org-netbeans-modules-rmi.xml) using FileSystem.runAtomicAction, the file listener on the Modules/ folder later receives two file change events, apparently identical including timestamp: org.openide.filesystems.FileEvent[source=Modules][file=Modules/org-netbeans-modules-rmi.xml,time=998071494763,expected=false] The first is ignored (because ModuleList was expecting to get one such change after rewriting the XML file), but the second appears to be an externally-initiated change and so ModuleList does extra work checking whether the XML on disk still matches the actual state of the module. Though it will find that everything is still OK and do nothing, some time was wasted doing this check, and under some circumstances the extra event could cause synchronization bugs. Radek do you know of any problems in FileSystems API that would cause the filesystem to fire duplicate file events? In this example the file was on the system file system; originally only in the netbeans.home layer; ModuleList inside an atomic block got its lock then output stream, wrote some content (thus to the netbeans.user layer), then released the lock and exited the block. The FileListener was attached to the containing folder Modules/ during IDE startup.
Probably source of this problem is meachanism that is used to modify content of FileObject using output stream: from read-only layer is file copied on writable layer. This should be done transparently for MFO user without firing any events.
Right, if a file already exists in an MFO, moving it to a different layer by writing to it should just fire the one FileChangeEvent and no more, I think... are there any unit tests covering this sort of thing?
Fixed in trunk. MFO.getOutputStream doesn`t fire fileChangeEvent any more. Only close of stream will fire fileChangeEvent. You are right that this problem should be covered with unit test: so new testGetOutputStream1 was added.
Resolved for 3.4.x or earlier, no new info since then -> verified
Resolved for 3.4.x or earlier, no new info since then -> closing.