1
0
Fork 0
mirror of https://github.com/eclipse-cdt/cdt synced 2025-07-15 13:05:22 +02:00

[249544] Save conflict dialog appears when saving files in the editor

This commit is contained in:
David McKnight 2008-11-07 17:12:38 +00:00
parent abc30da563
commit fc356e5aab
2 changed files with 56 additions and 3 deletions

View file

@ -34,6 +34,7 @@
* David McKnight (IBM) - [229610] [api] File transfers should use workspace text file encoding * David McKnight (IBM) - [229610] [api] File transfers should use workspace text file encoding
* David McKnight (IBM) - [235221] Files truncated on exit of Eclipse * David McKnight (IBM) - [235221] Files truncated on exit of Eclipse
* David McKnight (IBM) - [247189] SystemEditableRemoteFile.openEditor() not updating the default editor properly * David McKnight (IBM) - [247189] SystemEditableRemoteFile.openEditor() not updating the default editor properly
* David McKnight (IBM) - [249544] Save conflict dialog appears when saving files in the editor
*******************************************************************************/ *******************************************************************************/
package org.eclipse.rse.files.ui.resources; package org.eclipse.rse.files.ui.resources;
@ -700,6 +701,7 @@ public class SystemEditableRemoteFile implements ISystemEditableRemoteObject, IP
// reget the remote file so that we have the right timestamps // reget the remote file so that we have the right timestamps
try try
{ {
remoteFile.markStale(true); // as per bug 249544, we should mark stale to ensure we get a fresh copy
remoteFile = fs.getRemoteFileObject(remoteFile.getAbsolutePath(), new NullProgressMonitor()); remoteFile = fs.getRemoteFileObject(remoteFile.getAbsolutePath(), new NullProgressMonitor());
} }
catch (Exception e) catch (Exception e)

View file

@ -257,14 +257,65 @@ public class SystemUniversalTempFileListener extends SystemTempFileListener
} }
/**
* This method attempts to upload a temporary file in the workspace to a corresponding remote file location. It
* checks whether the timestamp of the remote file has changed since the temporary file was last known to
* be in synch with the remote file. If the timestamp has not changed, then it is assumed that the remote
* file has not changed and therefore it is safe to do an upload. If the timestamp has changed, then the remote
* file must have changed independently and there is a conflict and the upload conflict action is invoked.
*
* <p>
* <b>Warning</b> It is important to make sure that the remoteFile that gets passed in is up-to-date AND is the
* current cached version. If the remoteFile is not up-to-date then the timestamp of the actual remote file may
* be wrong and lead to the following problems:
*
* <ul>
* <li> If the detected remote timestamp is not the actual remote timestamp but it is the same as the storedModifiedStamp, an
* upload without detecting a conflict will cause lost data on the remote side!
* <li> If the detected remote timestamp is not the actual remote timestamp and the actual timestamp is the same as the
* storedModifiedStamp, a conflict will be indicated that doesn't actually exist
* </ul>
*
* If the remoteFile is not the current cached version then the following problem occurs. After the upload, the remote file is
* marked stale so that the up-to-date remote file can be retrieved with the updated actual timestamp. Because the remoteFile
* that was passed into this method is not the cached version, marking it stale will not mark the cached version stale and
* thus, when a re-query of the file is done after the upload, the original cached version gets returned as opposed to a fresh
* version with the correct timestamp.
*
* <p>
* Because of these problems, it is recommended that, before calling upload(), the remoteFile is retrieved from the cache and is
* marked stale like the following example:
*
* <code>
* ...
* // get the remote file from the cache
* IRemoteFile remoteFile = fs.getRemoteFileObject(remoteFile.getAbsolutePath(), monitor);
*
* // mark it stale
* remoteFile.markStale(true);
*
* // re-query the remote file to make sure you have the latest
* remoteFile = fs.getRemoteFileObject(remoteFile.getAbsolutePath(), monitor);
*
* // call upload
* upload(fs, remoteFile, ...);
* ....
* </code>
*
*
* @param fs the file subsystem that corresponds with the file to upload
* @param remoteFile the remote file location to upload to
* @param tempFile the source temp file to upload
* @param properties the remote file properties of the file to upload
* @param storedModifiedStamp the last timestamp of the remote file for which a temp file was in synch with the remote file
* @param editable the wrapper that associates the remote file, temp file and editor together
* @param monitor the progress monitor
*/
public void upload(IRemoteFileSubSystem fs, IRemoteFile remoteFile, IFile tempFile, SystemIFileProperties properties, public void upload(IRemoteFileSubSystem fs, IRemoteFile remoteFile, IFile tempFile, SystemIFileProperties properties,
long storedModifiedStamp, SystemEditableRemoteFile editable, IProgressMonitor monitor) long storedModifiedStamp, SystemEditableRemoteFile editable, IProgressMonitor monitor)
{ {
try try
{ {
// make sure the remote file is the current cached version
remoteFile = fs.getRemoteFileObject(remoteFile.getAbsolutePath(), monitor);
// get the remote modified timestamp // get the remote modified timestamp
long remoteModifiedStamp = remoteFile.getLastModified(); long remoteModifiedStamp = remoteFile.getLastModified();