Community
Participate
Working Groups
In the CVS move/delete hook, I want to perform the following steps for a move: 1) Move sync info from session property cache to ISynchronizer. 2) perform a tree.standardMove 3) flush the sync info for the moved resources (i.e. flush any session properties) I don't want to do step 3 unless I know that step 2 succeeded. However, I have no way of knowing this so I must just assume that it worked (which is probably OK is this case). Another scenarion involves delete. We are maintaining dirty status for folders as session properites. It would be nice to get some indication as to whether the operation succeeded or not (i.e. if it succeeded, we're OK otherwise we need to perform some sort of recovery).
Another scenario where this would be helpful is in bug 28300. We currently need to use a pre_auto_build lisenter to ensure that instances of RepositoryProvider are consistent after a project move. It would be more efficient to do this in the Move/Delete hook but we can't because we don't know if the operation succeeded.
I also find the "silent" failure of move to be undesirable in general. One scenario that I found: if for whatever reason, something is holding onto a file (say, a running process that never closed the file handle), java.io.File.rename will fail. The problem here is, in FileSystemStore.move(), if rename fails, it tries to do a copy and then a delete, but it never checks to see if the delete succeeded. As a result, the move will fail silently. The following snippet is from FileSystemStore.move(). Note the return code from Workspace.clear() is never checked. if (success) Workspace.clear(source); else { if (!canceled) { // We do not want to delete the destination in case of failure. It might // the case where we already had contents in the destination, so we would // be deleting resources we don't know about and the user might lose data. String message = Policy.bind("localstore.couldnotMove", source.getAbsolutePath()); //$NON-NLS-1$ throw new ResourceException(new ResourceStatus(IResourceStatus.FAILED_WRITE_LOCAL, new Path(source.getAbsolutePath()), message, null)); } }
Comment 2 refers to a different issue, addressed in bug 32076.
Time to move this one out of the inbox...
Not planning to address this.
