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.
Summary: | Can't create a file with content atomically | ||
---|---|---|---|
Product: | platform | Reporter: | Erno Mononen <emononen> |
Component: | Filesystems | Assignee: | rmatous <rmatous> |
Status: | RESOLVED FIXED | ||
Severity: | blocker | CC: | abadea, jtulach, msandor, tstupka |
Priority: | P2 | Keywords: | REGRESSION |
Version: | 6.x | ||
Hardware: | All | ||
OS: | All | ||
Issue Type: | DEFECT | Exception Reporter: | |
Bug Depends on: | |||
Bug Blocks: | 95386 |
Description
Erno Mononen
2007-02-15 13:48:40 UTC
FileSystem.AtomicAction guarantees just that events created during atomic action are fired after atomic action has finished. There is no guarantee that the association of the data object should happen when the file has been fully constructed. I don't know how to 100% prevent it with current API. No bug in FS. Have there been any changes in this area lately? This used to work after doing the copying inside of an AtomicAction. Although I can not say when exactly this stopped working, it does work in 5.5. I'm inclined to think that the change related to this is not in our code, since the same behaviour can be observed with other DataObjects as well (for example with the DDDataObject that is associated with web.xml file). Not aware about changes in FS. OK, any chance to get this enhancement implemented for 6.0? Although for now I can probably workaround this by creating the file with a different extension and renaming it then. I don't plan it for 6.0. As the stack traces in issue 95386 desc7 prove, the contract of FileSystem.runAtomicAction(), which states that in an atomic action no file change events for the respective file system are fired, is broken: the master file system sends some events under its friend contract with the VCS modules. The local history module has the opportunity to recognize the file before it has been fully created (from j2ee/persistence's point of view). Although it might be possible to fix the local history module for now, the hook that the master file system causes the whole AtomicAction concept to be unreliable. Perhaps the could be a way (and it would be sufficient for the VCS modules) to send these events upon exiting the AtomicAction, but before the regular FileChangeEvent's are sent. I hasitate that issue 95386 desc7 proves broken contract: 1/ FilesystemInterceptor$DelegatingInterceptor.beforeCreate line: 309 is called before FileObject is actually created - so there shouldn't be any problem 2/called when atomic action exited - which is right FilesystemInterceptor$DelegatingInterceptor.afterCreate line: 319 FilesystemInterceptor.fileDataCreated line: 148 FCLSupport.dispatchEvent line: 75 FileObject$ED.dispatch line: 891 EventControl.invokeDispatchers line: 181 EventControl.exitAtomicAction line: 155 So, I probably missed something - could you explain? There is method createSucces which is called before atomic action is finished, but this isn't nowhere mentioned in your stacktraces. Moreover Maros claimed that they actually do not use this method - so we could either eliminate createSucces or I can fix it in filesystems - I have test proving it and also fix but I hasitate that its cause of your problem (see the lines above). If you can reproduce the problem you should be also able to trace the problem. Sorry, I overlooked createSucces in the first stacktrace because beforeCreate attracted my attention. Fixed. But as I said I think that method createSucces is now useless and is not necessary. Maros, Tomas, please comment. /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/MasterFileObject.java,v <-- MasterFileObject.java new revision: 1.63; previous revision: 1.62 /cvs/openide/masterfs/src/org/netbeans/modules/masterfs/Delegate.java,v <-- Delegate.java new revision: 1.25; previous revision: 1.24 test/unit/src/org/netbeans/modules/masterfs/providers/ProvidedExtensionsTest.java; /cvs/openide/masterfs/test/unit/src/org/netbeans/modules/masterfs/providers/ProvidedExtensionsTest.java,v <-- ProvidedExtensionsTest.java new revision: 1.7; previous revision: 1.6 - as much i know the versioning spi (and so the Local History) doesn't depend on createSucces. - regarding issue #95386 - since some time the Local History doesn't go after fileobjects while processing events from the FS OK, but do you need then createSuccess anymore? Can we delete it from our frined contract if this method more or less duplicates fileDataCreated? We use beforeCreate(FileObject parent, String name, boolean isFolder); createSuccess() and createFailure() are not used now and can be deleted IMHO if it solves the issue. |