Community
Participate
Working Groups
Renaming a file within a zip works, but when the operation completes, the node reflects the old name. With the node selected, clicking "Refresh information on selected resource" does not cause an update. It takes a refresh on the parent node to get the child to display the correct name. For example, if I rename a.txt to b.txt within file.zip, the node continues to be labeled a.zip. If I click refresh, it's still a.zip. If I click on file.zip and hit refresh, a.txt will change to b.txt. -----------Enter bugs above this line----------- RSE 1.0 Testing round 2 installation : eclipse-platform-3.2 (M20060629-1905) RSE install : update-site RSE-complete java.runtime : Sun 1.5.0_07-b03 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Windows-local ------------------------------------------------
I guess this depends on bug 143458 (Refresh on a normal file does not work)
This might be fixed already with the fix for bug #181145.
Renaming a file inside a zip now displays the new name when the operation completes. Verified on 2.0M7.
It works fine on Local, and also files inside zip on dstore. But when I try to rename a folder inside a zip on dstore, it fails. Instead of the renamed folder, I get an error message. When I then refresh the ZIP archive, I can browse into it and see that the folder has actually been renamed. Verification of this needs to take 4 cases into account - files and folders on local and dstore, and the combination of them.
I did some debugging and found out the problem was probably in the dstore server side. The zip file I used to recreate this problem had one folder called 6YLT5X, and inside this folder, I had four subfolders. If I renamed the main folder 6YLT5X, there was no problem. But if I expanded 6YLT5X, and renamed one of the subfolder, I got a message attaching to the node saying folder 6YLT5X was not readable. After debugging, I could see the isReadable properties of the dataElement of virtual folder 6YLT5X was correct right after I expanded the zip file. But after I expanded the 6YLT5X folder itself (which in turn invoked the coresponding datastore query command) to get its children information, the readable attribute of the dataElement sent back from the backend for the 6YLT5X itself was changed to the default value (false) as well as some of other attributes. When we renamed its child folder, one of the checking was to see if its parent is readable, which is failed in this case. So a SystemMessage Exception is create, which resulted the error message attach to the node 6YLT5X. I will try to debug its server code tomorrow to find out more details.
The problem is that in UniversalFileSystemMiner#handleQueryAllArchive(), the function mgr.getVirtualObject() was called by passing the "virtualPath" of the folder. But this function actually expect a full path of the virtual folder. So the checking for isVirtual() inside this function return false, and a new VirtualChild is contructed and returned with the default value. Change the mgr.getVirtualObject() call passing "path" instead of "virtualPath".
Created attachment 68673 [details] Change virtualPath to path in UniversalFileSystemMiner#handleQueryAllArchive Legal Message: I, Xuan Chen, declare that I developed attached code from scratch, without referencing any 3rd party materials except material licensed under the EPL. I am authorized by my employer, IBM Canada Ltd. to make this contribution under the EPL.
I've applied the patch.
Verified fixed on RC1.
closing.
[target cleanup] 2.0 RC1 was the original target milestone for this bug
