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.
unit test in o.n.m.versionig/DeleteCreateTest.java
I will attach a patch which should reflect our discussion. Please, look at it. Previously BaseFileObj.FileChangeListenerForVersioning triggered ProvidedExtensions (e.g. fileDeleted -> deleteSuccess). That's why events were fired in different order in case of AtomicAction. I removed FileChangeListenerForVersioning and I call methods from ProvidedExtensions directly. I also added ProvidedExtensions.deletedExternally and createdExternally which are called when refresh in FileSystem detects deleted or created files and it is about to fire events. With suggested implementation order of events in the DeleteCreateTest is the following: beforeDelete getDeleteHandler getDeleteHandler.delete fileDeleted deleteSuccess beforeCreate createSuccess fileDataCreated ----- with AtomicAction -------------------------- beforeDelete getDeleteHandler getDeleteHandler.delete deleteSuccess beforeCreate createSuccess fileDeleted fileDataCreated FileChangeEvents are not fired until AtomicAction is finished but ProvidedExtensions methods instantly.
Created attachment 63334 [details] Patch of masterfs.
Looks promising to me. If it really works for vcs guys, then please add: 1. tests 2. increment spec version of the module 3. @since 4. apichange note
looks like what we wanted
Maybe I'm mistaken, BUT createSuccess was originally called after AtomicAction and now as soon as method delete is finished, is it? Not sure but (as I remember) could lead to to problems because then FS issues instanceS of FileObject of newly created file before intended(empty file) => wrong data object assigned, mime type, ....
Originally, createSuccess was triggered by FileChangeListenerForVersioning.fileDataCreated, i.e. after AtomicAction. But FileObject for newly created file is always created immediatelly inside AtomicAction (FileObject.createData() returns created FileObject). From FS point of view it seems transparent. But I don't know what versioning needs. If you want to be informed immediatelly when file is created, use createSuccess. If you want to wait until AtomicAction finishes, use FileChangeListener.fileDataCreated.
Radek refers to problem when VCS tried to access DataObjects for not yet finished FileObjects. Guys, please do not do that. Do not leak these FileObjects sent to you through masterfs API anywhere. If we can trust in this, then it is OK to notify the events as soon as Jirka knows about them.
I will attach new patch (apply it to masterfs/src) which adds ProvidedExtensions.fileChanged() method. It is also called immediatelly regardless it is in AtomicAction or not. Let me know if it suites for you. If yes, I will add tests and other things as Jarda requested.
Created attachment 63433 [details] Updated patch.
Please, evaluate and reassign back to me if you want me to integrate proposed changes.
We are missing one thing in the proposed patch: it is not possible NOT to handle a Move operation and have a callback when it completes. For Delete operations it works fine because we have a deleteSuccess() callback but there is no moveSuccess() callback.
I added beforeMove, moveSuccess and moveFailure to InterceptionListener. Reassigning back for evaluation.
Created attachment 68435 [details] Updated patch with beforeMove, moveSuccess and moveFailure.
will it be fixed in 65? There is not much time.
We will integrate it after 6.5 is out.
6.5 is cloned ... proceed with integration please
Created attachment 99753 [details] updated patch last patch version became outdated in the meantime.
Created attachment 99943 [details] updated patch new patch version: - added some corrections in o.n.m...FolderObj.refreshImpl(boolean, boolean) - deletedExternally wasn't called - changed the beforeMove, moveSuccess, moveFailure signatures: beforeMove(FileObject from) to moveSuccess(FileObject from, File to) moveSuccess(FileObject from) to moveSuccess(FileObject from, File to) moveFailure(FileObject from) to moveSuccess(FileObject from, File to) - added unit tests - apichanges, javadoc, @since & co.
Y01 Adding new methods into InterceptionListener is not compatible. Maybe you want to create interface InterfaceptionListener.Move extends InterceptionListener and instanceof at places where you call the new methods? Y02 Missing javadoc and @since in InterceptionListener new methods.
Created attachment 99971 [details] updated patch - removed the methods from InterceptionListener and left them only in ProvidedExtensions. handling the same way as e.g. createdExternally, deteledExternally, ... - adapted tests
will apply the last patch (id=99971)
http://hg.netbeans.org/cdev/rev/7bb7fc36a3ef fixed
Integrated into 'main-golden', will be available in build *201006230001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/7bb7fc36a3ef User: Tomas Stupka <tstupka@netbeans.org> Log: Issue #133855 - wrong event order when deleting and creating files in AtomicAction
Integrated into 'main-golden', will be available in build *201102260001* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress) Changeset: http://hg.netbeans.org/main/rev/d9521a9f5144 User: Tomas Stupka <tstupka@netbeans.org> Log: missing implementation for createdExternaly - should have been added together with #9fd543e21a3e (issue #133855)