Community
Participate
Working Groups
If I rename a file from an archive that is open and make changes to the file then save I get the Save Conflict Dialog. If I do this on a normal Local file I do not get the Save Conflict Dialog, so I would expect the same behavior for Archive's. Steps to Reproduce: 1. Create the archive dummy.zip on Local. 2. Create the file text.txt inside it. 3. Open text.txt. 4. Rename text.txt. 5. Make a change to text.txt in the editor and press Save. --> Save Conflict Dialog Appears -----------Enter bugs above this line----------- TM 2.0RC4 Testing installation : eclipse-SDK-3.3RC4 RSE install : RSE 2.0 RC4 java.runtime : Sun 1.5.0_11-b03 os.name: : Windows XP, Service Pack 2 ------------------------------------------------
Xuan - you've been most exposed to archives recently, can you debug this?
Sure.
If you rename a regular file, you could see its last modified time will not change. (you could try it in the command line as well). But that is not the case for virtual file processing. If user wants to rename a virtual file, under cover, we recreate a new archive file with the virtual file name changed to the new name, and then replace the old archive file with the new one. So the last modify time of this new archive file as well as all its virtual files are different from the old ones. So in the case described in this bug (save after rename for a virtual file), the following checking in SystemUniversalTempFileListener#upload(): ****************************************************************************** try { // get the remote modified timestamp long remoteModifiedStamp = remoteFile.getLastModified(); boolean remoteFileDeleted = !remoteFile.exists(); // compare timestamps if (remoteFileDeleted || (storedModifiedStamp == remoteModifiedStamp)) ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ { // timestamps are the same, so the remote file hasn't changed since our last download try { ********************************************************* failed. So the Save Conflict diaglog will be putup. It is a limitation for the way we process renaming of a virtual file. I will mark it as WONTFIX.
I cannot follow your argument: Even if the timestamp of the archive is changed, the timestamps of the virtual files inside the archive should not change. Assume zipping up some software which all expects to have timestamp 01-01-2008. Then adding one more file later on. The timestamp of the archive would change, but the virtual files inside the archive are all unchanged so their timestamps should not change. If our archive handlers don't work that way, I would think it's a bug.
I just checked the local connection case. If I rename/paste/delete a virtual file, the "Last Modified Time" of archive file as well as all it virtual files/folders are all changed. I will open a different bug to keep track of the problem.
bug 214251 has been opened, and used to deal with save conflict problem for local. I will use this bug to fix problem exists on the dstore side.
Created attachment 86353 [details] fix for this problem. Fix includes: Make sure the GetRemoteObject command could be applied to file/folder object. It used to only apply to filter object. Change UniversalFileSystemMiner#handleQueryGetRemoteObject() so that it could deal with virtual file/folder properly. I also use this bug to remove a couple println() statements from CopyThread and DeleteThread.
I've committed the fix to cvs.
Close since it is fixed.
