Attachment 117337 Details for Bug 249544 – patch with javadoc for upload() and marking the file stale before calling upload

[patch] patch with javadoc for upload() and marking the file stale before calling upload

patch.txt (text/plain), 5.71 KB, created by David McKnight

on 2008-11-07 12:02:51 EST

(hide)

Description:

Filename:

MIME Type:

Creator: David McKnight

Created: 2008-11-07 12:02:51 EST

Size: 5.71 KB

patch

obsolete

>### Eclipse Workspace Patch 1.0
>#P org.eclipse.rse.files.ui
>Index: src/org/eclipse/rse/files/ui/resources/SystemUniversalTempFileListener.java
>===================================================================
>RCS file: /cvsroot/dsdp/org.eclipse.tm.rse/plugins/org.eclipse.rse.files.ui/src/org/eclipse/rse/files/ui/resources/SystemUniversalTempFileListener.java,v
>retrieving revision 1.31
>diff -u -r1.31 SystemUniversalTempFileListener.java
>--- src/org/eclipse/rse/files/ui/resources/SystemUniversalTempFileListener.java	21 Oct 2008 15:40:03 -0000	1.31
>+++ src/org/eclipse/rse/files/ui/resources/SystemUniversalTempFileListener.java	7 Nov 2008 17:00:44 -0000
>@@ -257,14 +257,65 @@
> 
> 	}
> 
>+	/**
>+	 * 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 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 refresh
>+	 * version with the correct timestamp. 
>+	 * 
>+	 * <p>
>+	 * Because of these problems, it is recommended that, before calling upload(), the remoteFile is retrieved from the cached and
>+	 * marked stale and 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, 
> 				long storedModifiedStamp, SystemEditableRemoteFile editable, IProgressMonitor monitor)
> 	{
> 		try
> 		{
>-			// make sure the remote file is the current cached version			
>-			remoteFile = fs.getRemoteFileObject(remoteFile.getAbsolutePath(), monitor);
>-			
> 			// get the remote modified timestamp
> 			long remoteModifiedStamp = remoteFile.getLastModified();
> 			
>Index: src/org/eclipse/rse/files/ui/resources/SystemEditableRemoteFile.java
>===================================================================
>RCS file: /cvsroot/dsdp/org.eclipse.tm.rse/plugins/org.eclipse.rse.files.ui/src/org/eclipse/rse/files/ui/resources/SystemEditableRemoteFile.java,v
>retrieving revision 1.64
>diff -u -r1.64 SystemEditableRemoteFile.java
>--- src/org/eclipse/rse/files/ui/resources/SystemEditableRemoteFile.java	17 Sep 2008 15:39:35 -0000	1.64
>+++ src/org/eclipse/rse/files/ui/resources/SystemEditableRemoteFile.java	7 Nov 2008 17:00:44 -0000
>@@ -34,6 +34,7 @@
>  * 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)        - [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;
>@@ -700,6 +701,7 @@
> 		// reget the remote file so that we have the right timestamps
> 		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());
> 		}
> 		catch (Exception e)

Actions: View | Diff

Attachments on bug 249544: 114197 | 114226 | 114319 | 115642 | 117337