Bug 311218

Comment 1 David McKnight 2010-05-27 14:33:49 EDT

Without having a UI scenario or example code to use in order to reproduce the problem, it's difficult to speculate what you're running into.  With the steps described, should I be able to reproduce this?  I tried following the steps but to no avail (I'm assuming the all file attribute changes occur via RSE, as opposed to outside of Eclipse).

Comment 2 Samuel Wu 2010-05-28 11:06:30 EDT

The listed steps was how we reproduced the problem. And the file content update and file attribute change happened outside eclipse.

Comment 3 David McKnight 2010-05-28 12:20:01 EDT

(In reply to comment #2)
> The listed steps was how we reproduced the problem. And the file content update
> and file attribute change happened outside eclipse.

Hmm, I've tried to reproduce this using both the HEAD stream and the latest from the RSE 3.0.x maintenance stream but so far I've been unable to reproduce the problem using the steps described.  I asked a colleague to try but he couldn't reproduce it either.  Is there anything that may be missing from the steps?

Comment 4 Miles Parker 2010-05-29 19:28:52 EDT

*** Bug 314989 has been marked as a duplicate of this bug. ***

Comment 5 Samuel Wu 2010-06-08 12:53:09 EDT

That's the way we reproduced the probem. The call is an API call and run by our UI. I don't know what else happened which may have impact on RSE.

Comment 6 David McKnight 2010-06-08 13:03:17 EDT

(In reply to comment #5)
> That's the way we reproduced the probem. The call is an API call and run by our
> UI. I don't know what else happened which may have impact on RSE.

I understand that you can reproduce the problem via the API call.  I'm wondering if there's something missing from the steps you described for reproducing it via RSE (as opposed to your API call):

> The scenario is like the following.
> 1. The API is called to download the readonly file from windows local file
> system to RSE cache
> 2. Change the file attribute to make the file editable and make a change to the
> file.
> 3. Change the file attribute back to readonly.
> 4. Call the API again to download the file.
> There is a content conflict dialog pops up. It shouldn't since there is no
> change to the cached file.

Are you still able to consistently reproduce it this way?

Comment 7 Samuel Wu 2010-06-09 21:12:18 EDT

More details on the problem reproducing.
Here is how our action calls the API.
1. Our action actually copy the local file and upload it to a remote host.
2. UniversalFileTransferUtility.copyRemoteResourceToWorkspace(IRemoteFile, IProgressMonitor) line: 2955 is called which calls UniversalFileTransferUtility.downloadResourceToWorkspace(IRemoteFile, IProgressMonitor) line: 1186	to create a copy of the file in the RSE cache
2. The parent folder of the file is refreshed.
directory.refreshLocal(IResource.DEPTH_ONE, null);
3. Get the remote folder 
IRomoteFile newTargetFolder = targetFS.getRemoteFileObject(newPath, null);
4. Get all the file children of the local folder
IResource[] children = directory.members();
5. Upload the local cache to remote
targetFS.upload(srcFileLocation, srcCharSet, newPath, targetFS.getRemoteEncoding(), monitor);		

I found it's much easier to reproduce the problem when copy/paste the parent folder of the local read only file.
Hope this helps you to reproduce it.

Comment 8 David McKnight 2010-06-10 16:18:44 EDT

Created attachment 171670 [details]
patch to check and set properties via universal transfer utility

I have an idea of what the problem may be but I'm not sure.  Samuel, could you try your scenario with this patch?

Comment 9 Samuel Wu 2010-06-11 07:43:02 EDT

After the patch, I got the following error message 
RSEF1002, 
Operation failed. File system input or output error, 
Message reported from file system: File 5585.txt can not be saved on LOCALHOST. You do not have write access to the file.
The file was actually pasted on the host with the updated content.

Comment 10 David McKnight 2010-06-11 08:24:34 EDT

Samuel, could you please post an actual testcase?  An action contribution with code that reproduces the bug would be preferable since trying to guess at how to reproduce this is turning out to be a waste of time.

Comment 11 Samuel Wu 2010-06-13 12:47:28 EDT

Dave,
The problem was reproduced using the following code.

ISystemRegistry registry = RSECorePlugin.getTheSystemRegistry();
IHost localConnection = registry.getLocalHost();
IRemoteFileSubSystem ss = RemoteFileUtility.getFileSubSystem(localConnection);
IProgressMonitor monitor = new NullProgressMonitor();
String localDirPath = "D:\\temp\\5585";
try {
	IRemoteFile localDir = ss.getRemoteFileObject(localDirPath, monitor);
	UniversalFileTransferUtility.copyRemoteResourceToWorkspace(localDir, new NullProgressMonitor());
	if (true)
		return ;
}
catch (Exception e){
}

Comment 12 Samuel Wu 2010-06-13 12:48:31 EDT

Dirctory D:\temp\5585 contain a readonly file test.txt

Comment 13 David McKnight 2010-06-14 11:22:03 EDT

(In reply to comment #11)
> Dave,
> The problem was reproduced using the following code.
> 
> ISystemRegistry registry = RSECorePlugin.getTheSystemRegistry();
> IHost localConnection = registry.getLocalHost();
> IRemoteFileSubSystem ss = RemoteFileUtility.getFileSubSystem(localConnection);
> IProgressMonitor monitor = new NullProgressMonitor();
> String localDirPath = "D:\\temp\\5585";
> try {
>     IRemoteFile localDir = ss.getRemoteFileObject(localDirPath, monitor);
>     UniversalFileTransferUtility.copyRemoteResourceToWorkspace(localDir, new
> NullProgressMonitor());
>     if (true)
>         return ;
> }
> catch (Exception e){
> }

I tried this both with and without the patch.  Without the patch, I notice that, if I change the read-only property of the file on the file system and then run the test, the property is not updated.  With the patch, the property is updated.  In either case, however, I don't hit a conflict dialog.  With the sample code, are there steps you had to take that would reproduce the conflict?

Comment 14 Samuel Wu 2010-06-14 11:40:56 EDT

Here are my steps.
1. Run the action to download the parent directory of the readonly file
2. Change the file properties in windows explorer and update the file
3. Change the file properties back to readonly
4. Run the action again
I got the conflick pops up
Were you testing it on 3.2 or 3.0.3.x? I'm on 3.0.3.x

Comment 15 David McKnight 2010-06-14 12:17:56 EDT

(In reply to comment #14)
> Here are my steps.
> 1. Run the action to download the parent directory of the readonly file
> 2. Change the file properties in windows explorer and update the file
> 3. Change the file properties back to readonly
> 4. Run the action again
> I got the conflick pops up
> Were you testing it on 3.2 or 3.0.3.x? I'm on 3.0.3.x

I've tried this with both the 3.2 and 3.0.3.x environments and I still haven't hit a conflict dialog.  When changing the file properties in Windows Explorer, I simply toggle the read-only checkbox in the properties dialog - is this what you do too?

Comment 16 Samuel Wu 2010-06-14 12:23:20 EDT

Step 2
2. Change the file properties in windows explorer and update the file

You need to make a change to the file, close the file and change the file back to read only.

Comment 17 David McKnight 2010-06-14 13:26:19 EDT

Created attachment 171849 [details]
updated patch with marked download timestamp

I've managed to reproduce this now.  I think the problem is that tempFile.getLastModified() is not always accurate and hence the SystemTempFileListener gets a different value from tempFile.getLocation().toFile().lastModified() indicating that there is a change to the temp file for upload.  The patch should rectify that.  Could you try it?

Comment 18 Samuel Wu 2010-06-14 14:28:09 EDT

Thanks for the fix, Dave.
Please port it back to 3.0.3. Bug 316798 is opened.

Comment 19 David McKnight 2010-06-23 10:06:39 EDT

I've committed the change to cvs.