Please use the Apache issue tracking system for new NetBeans issues (https://issues.apache.org/jira/projects/NETBEANS0/issues) !!
Bug 95675 - Can't create a file with content atomically
Can't create a file with content atomically
Status: RESOLVED FIXED
Product: platform
Classification: Unclassified
Component: Filesystems
6.x
All All
: P2 (vote)
: 6.x
Assigned To: rmatous
issues@platform
: REGRESSION
Depends on:
Blocks: 95386
  Show dependency treegraph
 
Reported: 2007-02-15 13:48 UTC by Erno Mononen
Modified: 2008-12-22 11:50 UTC (History)
4 users (show)

See Also:
Issue Type: DEFECT
:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Erno Mononen 2007-02-15 13:48:40 UTC
(sources from 0214)

I have a piece of code that creates a persistence.xml file with some initial 
content (namely with the declaration) inside of a FileSystem.AtomicAction by 
using the FileUtil.copyFile(..) method. I'm however observing that the 
DataObject.find(fo) method is called before the created file has any content, 
which causes the file to be associated with an incorrect DataObject. This 
behaviour seems to be introduced quite lately, perhaps during this week. 

The code for creating the file is as follows (you can find it in the j2ee/
persistence module, 
org.netbeans.modules.j2ee.persistence.provider.ProviderUtil#createPersistenceDDFile(Project)):

persistenceLocation.getFileSystem().runAtomicAction(new 
FileSystem.AtomicAction() {
  public void run() {
    try {
      dd[0] = 
FileUtil.copyFile(Repository.getDefault().getDefaultFileSystem().findResource(
                                "org-netbeans-modules-j2ee-persistence/
persistence-1.0.xml"), persistenceLocation, "persistence", "xml"); //NOI18N
             } catch (IOException ex) {
                ErrorManager.getDefault().notify(ex);
            }
       }
});
    
To my understanding using the AtomicAction should guarantee that the 
association of the data object should happen when the file has been fully 
constructed, is that correct or is there another way to achieve the desired 
behaviour?
Comment 1 rmatous 2007-02-15 14:38:50 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.
Comment 2 Erno Mononen 2007-02-15 15:02:44 UTC
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).
Comment 3 rmatous 2007-02-15 15:26:59 UTC
Not aware about changes in FS.
Comment 4 Erno Mononen 2007-02-15 16:32:49 UTC
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.
Comment 5 rmatous 2007-02-15 16:43:51 UTC
I don't plan it for 6.0.
Comment 6 Andrei Badea 2007-02-23 16:14:52 UTC
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.
Comment 7 rmatous 2007-03-20 14:22:38 UTC
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.
Comment 8 rmatous 2007-03-20 15:16:49 UTC
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
Comment 9 Tomas Stupka 2007-03-20 16:24:12 UTC
- 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
Comment 10 rmatous 2007-03-20 17:07:29 UTC
OK, but do you need then createSuccess anymore? Can we delete it from our frined
contract if this method more or less duplicates fileDataCreated?
Comment 11 Maros Sandor 2007-03-20 17:27:57 UTC
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.


By use of this website, you agree to the NetBeans Policies and Terms of Use. © 2014, Oracle Corporation and/or its affiliates. Sponsored by Oracle logo