### 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)