Community
Participate
Working Groups
Build ID: M20070212-1330 Steps To Reproduce: Scenario: RSA UML project source-controlled by ClearCase. User tries to modify a checked in model (without explicitly checking it out from ClearCase first). ClearCase gets the validateEdit call from the gmf editor and tries to checkout the file. ClearCase discovers that a later version of the file exists in the repository. ClearCase offers the user two choices - checkout the loaded version or checkout the latest version. If the user picks the 1st option, everything is fine. If they pick the "latest" option, the checkout succeeds but then they get an error message saying that "no modifications are allowed; resource is out of sync with the file system" (or something to that effect). More information: Debugging through the code, we've discovered that once our validateEdit returns an OK status, the GMF code tries to verify that the file is "in sync". The test includes comparing the length of the file before and after the call to validateEdit. Since ClearCase checks out a different version of the file, that test, of course, fails. The code I am referring to is in: package org.eclipse.gmf.runtime.emf.core.internal.util; public class FileValidator implements MSLFileModificationValidator { ..... public boolean hasFileChanged() { IPath path = file.getLocation(); if (path == null) { return false; } File ioFile = path.toFile(); if (ioFile == null) { return false; } // new timestamp Timestamp newTimestamp = new Timestamp(ioFile.lastModified()); newTimestamp.setNanos(0); return !(lastModified.getTime() == newTimestamp.getTime() && fileLength == ioFile .length()); } }
CVS has a similar setting in case that helps when trying to reproduce this (i.e. Watch/Edit can be configured to perform an update before editing). I've tried this with the GMF ecore editor and it does leave the editor in a bad state (i.e. the editor no longer saves and doesn't issue any error). The steps to follow with CVS are: 1) From the CVS properties of a CVS project containing an ecore model linked to the GMF ecore editor, check the "Enable watch/edit for this project" property. 2) In the Team>CVS>Watch/Edit preference page, check the 'Send CVS Notifications to the server", "Always Prompt" and "Prompt to update if out of date". 3) From a different workspace, commit a change to the ecore model file. 4) From your workspace, try to edit the ecore model using the GMF editor. You should be prompted to edit the file and then prompted to update. 5) After the file is updated, there are no errors but saving from the editor doesn't update the file on disk. Although this is not the same as the reported scenario, it may be related.
Are you usign lates version of GMF? I can not see org.eclipse.gmf.runtime.emf.core.internal.util.FileValidator in my org.eclipse.gmf.runtime.emf.core plugin in workspace.. Are you using generated code? Concerning the ClearCase problem - looks like ClearCase integration just update java.io.File on the local file system in this situation and leave eclipse Resource out of synch. CVS problem could be a little bit different - i suppose once ClearCase integration will be corrected, the results will be aligned with CVS scenario..
We are using whatever version of GMF comes with our RSA install. From the According to the About box, this is org.eclipse.gmf (1.0.3.v20070202-1200-gW3quizrSB1Fxqp) "Graphical Modeling Framework". Version: 1.0.0.I20060505-1400 Build id: 1.0.3 We actually do update the Eclipse resource by calling IResource.refreshLocal. Here is more code for you from the same FileValidator class in org.eclipse.gmf.runtime.emf.core.internal.util: public IStatus validateEdit(IFile[] files, Object shell) { IStatus status = Status.OK_STATUS; if (files == null || files.length == 0) { return status; } Set unsynchedFiles = new HashSet(); Map filesToModificationStamps = new HashMap(); if (!MSLUtil.DISABLE_SHARED_DYNAMIC_VIEW_SUPPORT) { for (int i = 0; i < files.length; i++) { IFile file = files[i]; filesToModificationStamps.put(file, new ModificationStamp(file)); boolean inSync = file.isSynchronized(IResource.DEPTH_ZERO); if (!inSync) { unsynchedFiles.add(file); } } if (!unsynchedFiles.isEmpty()) { status = buildOutOfSyncStatus(unsynchedFiles); } } if (status.isOK()) { status = ResourcesPlugin.getWorkspace().validateEdit(files, shell); if (!MSLUtil.DISABLE_SHARED_DYNAMIC_VIEW_SUPPORT) { for (Iterator entries = filesToModificationStamps.entrySet().iterator(); entries.hasNext();) { Map.Entry entry = (Map.Entry)entries.next(); IFile file = (IFile)entry.getKey(); ModificationStamp stamp = (ModificationStamp)entry.getValue(); if (stamp.hasFileChanged()) { unsynchedFiles.add(file); } } if (!unsynchedFiles.isEmpty()) { status = buildOutOfSyncStatus(unsynchedFiles); } } } return status; } Note how after the call to ResourcesPlugin.getWorkspace().validateEdit(), it goes over the set of ModificationStamp(s) it had collected before the call and calls stamp.hasFileChanged(). If it returns true, an error is buit. Like I said, the file is changed in our implementation of validateEdit(), it is intentional.
Reassigning to Runtime team as it seems to have nothing to do with the generated code or models.
*** This bug has been marked as a duplicate of bug 212178 ***
[GMF Restructure] Bug 319140 : product GMF and component Runtime EMF was the original product and component for this bug
