Community
Participate
Working Groups
This problem is found when I wrote the code to create source data for Junit test for archive handler. I created some folders in local connection, and then use drag/drop to copy them into another connection. And I found out that empty subfolders were not copied to the other connection. I could recreate it using normal RSE operation. Copy within the same connection worked fine.
Bulk update target milestone 2.0.1 -> 3.0
I have worked out a solution for M7 on this defect. I will be posting a patch after M6 is released. Regards, Rupen
Created attachment 95961 [details] Copy Empty folders across connections Here is a patch. Logic: SystemRemoteViewFileAdapter - doDrop method now adds the actual folder being copied across systems to the set in order to extract empty (sub)folders. Originally only files are being added to this set. UniveralFileTransferUtility - extracts the empty (sub)folders. Creates the parent folders if they do not exist, then creates the empty folders in the workspace to be copied. I, Rupen Mardirossian, 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.
Created attachment 95994 [details] Copy Empty Folders across connections repost with additional checks.
Rupen -- I have some concerns about the patch. In UniversalFileTranferUtility, you've modified the child set before recursing into subdirectories. Why? The child set used to contain files and folders, now it contains only folders. I haven't run the code, but it seem that this could cause files to be skipped on download. Second, if you REALLY want just folders in the invocation you should use the IFileService constant and not hardcode the value of 2. Third, in the section where you create the empty folders you print a stack trace if you receive a core exception. I know that this is done elsewhere is the code, but we're trying to remove these. In this case you should be logging the error rather than printing the stack trace. If the exception can safely be ignored, then the catch block should contain a comment explaining why this is so. In SystemViewRemoteFileAdapter, I'm not sure the comment expresses what is going on here. It looks like you're adding all folders from the original set to the flatset. The comment implies that you are only adding one folder and its not clear from the code that it is empty although the comment implies that as well. What's really going on here? Please fix up the patch, and check with DaveM or Xuan about the error handling.
Hey Dave, For the first comment: Initially, the childSet would not get populated because that portion of the code would never get hit. Before my changes, a set of FILES were being passed through this method and the check for instance of srcFile.isDirectory() was the pass to the code with the childSet. in the SystemViewRemoteFileAdapter, I am adding the folder(s) that are being copied to the flatset, as the flatset only contains files. Adding this/these folder will allow me to extract all empty folders in the UniversalFileTrasferUtility when the check for srcFile.isDirectory() gets hit. This is where we recurse for and search for empty folders since all the files have already been taken care of (all other objects in the flatSet) ie srcFile.isFile(). I will try and clean up comments a bit. For the second comment: I will change to constant. For the third comment: I will check with DaveM or Xuan as mentioned. Thank you, Rupen
Hey Dave D, I am adding you to the CC list, please check previous comment. Thank you
(In reply to comment #6) Good. Looking forward to the next version of the patch.
Created attachment 96872 [details] Copy Folders Across Connections Hey Dave, Here is an updated patch, please review when you have a minute. Thanks, Rupen
Rupen -- I tested the patch and it seems to work when going from a Local connection to an SSH connection, but when copying from SSH to Local the empty folders are not preserved. See if you can find out what's going on with this problem.
From debugging I have found that when going from SSH to Local, that the code that was implemented by myself does not get hit at all. A different route is taken as the flag for supportSearch is false. I am not familiar with this flag, is this what it is suppose to be returning. boolean supportsSearch = ((IRemoteFileSubSystemConfiguration)set.getSubSystem().getSubSystemConfiguration()).supportsSearch(); This operation also throws an exception, here is the stack trace (Also can be seen in the dev driver as I have not modified any of the code for this instance). To replicate, copy an empty folder from SSH to local. org.eclipse.core.internal.resources.ResourceException: Resource '/RemoteSystemsTempFiles/DMCKNIGH3/home/tester/RUPEN/EMPTY' does not exist. at org.eclipse.core.internal.resources.Resource.checkExists(Resource.java:316) at org.eclipse.core.internal.resources.Resource.checkAccessible(Resource.java:193) at org.eclipse.core.internal.resources.Container.members(Container.java:181) at org.eclipse.core.internal.resources.Container.members(Container.java:164) at org.eclipse.rse.files.ui.resources.UniversalFileTransferUtility.uploadResourcesFromWorkspace(UniversalFileTransferUtility.java:1602) at org.eclipse.rse.internal.files.ui.view.SystemViewRemoteFileAdapter.doDrop(SystemViewRemoteFileAdapter.java:2020) at org.eclipse.rse.internal.ui.view.SystemDNDTransferRunnable.transferRSEResources(SystemDNDTransferRunnable.java:219) at org.eclipse.rse.internal.ui.view.SystemDNDTransferRunnable.runInWorkspace(SystemDNDTransferRunnable.java:603) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:55) Basically what it is trying to do is copy a file from the workspace that does not exist. Should there be a seperate defect open on this one? Thoughts/suggestions? Rupen
Rupen -- Check with DaveM about the separate defect. supportsSearch should not affect copy. supportsSearch basically says that the resources exposed by this subsystem support a remote search of their content. I'm guessing the exception occurs because the temp files project does not have the empty folder in it. This should be fixed if you can find out why supportsSearch is affecting the code path. It looks like code is constructing a set of files that should be accessed, downloading them, and then copying them. If DaveM wants another defect opened, then I will commit this patch and answer this defect as fixed. -- DaveD
After further investigation, it seems that if support search is not supported it will use a different copy method as mentioned before and actually pass the folder thats being copied (if a folder is being copied). The method strips out the children recursively and downloads any files of this folder (which there are none because of it being empty). Thereafter it attempts to copy this resource (which doesn't exist) from the workspace causing the exception. I will work a solution for this method to deal with empty folders and repost a patch today. Rupen
Created attachment 97269 [details] Copy Empty Folders Across Connections Hey Dave, Here is the new patch addressing SSH as well, Please review when you have a minute. Thanks, Rupen
Created attachment 97980 [details] Copy Empty Folders Across Connections reposting due to merge conflict, please review.
Rupen -- I noticed that the "create empty folders" code appears now appears to be duplicated. Please refactor this into a private method rather than duplicating the code. -- Dave
Created attachment 98061 [details] Copy Empty Folders Across Connections refactored into a private method as suggested. Thank you, Rupen
Committed patch as-is.
