Community
Participate
Working Groups
Cannot Copy & Paste from RSE FileSubsystem into the Eclipse Resource Navigator --> Message "Cannot paste into selected elements". Copy & Paste from Resource Naviagor into RSE FileSubsystem does work. But Drag & Drop doesn't seem to work properly. Cannot Drag & Drop from RSE FileSubsystem into Windows Explorer. --> Simply doesnt work Cannot Drag & Drop from Windows Explorer into RSE FileSubsystem --> org.eclipse.swt.SWTException: Data does not have correct format for type
I looked at this briefly and realize there may be a bit of design work required here. There used to be a coupling between some of this support (the SystemDropActionDelegate) and the file subsystem support. But, because the drag and drop/copy paste framework is generic, it needs to be independent of the file system support. Any ideas on how we ought to separate the file DND support from the generic?
I've fixed the drag and drop for RSE to Navigator. The problem I see with copy & paste is that the Navigator enables paste based on FileTransfer data types, which are basically local file paths (same as used in windows explorer). In order to get local file paths for RSE resources, we'd have to copy the files to local in the copy action (i.e. before the paste). I'm not sure whether we want to do that. Any thoughts?
Initiating a download when the user chooses "Copy" would be nonstandard I think. The actual download should only happen when "Paste" is invoked. Do you see any chance how this could be done? For instance, by using a PluginTransfer instead of a FileTransfer? Or deferring the actual download by some other means?
Current status as of HEAD on 20-Sep-2006: Drag&Drop RSE-Local -> Windows Explorer : FAIL -> Eclipse Project Explorer : FAIL -> Eclipse Navigator : OK Windows Explorer -> RSE-Local : File -> FAIL Folder -> OK Eclipse Navigator -> RSE-Local : File -> FAIL Folder -> OK Eclipse Project Explorer -> RSE-Local : FAIL Copy&Paste RSE-Local -> Windows Explorer : FAIL -> Eclipse Project Explorer : FAIL -> Eclipse Navigator : FAIL Windows Explorer -> RSE-Local : File -> FAIL Folder -> OK Eclipse Navigator -> RSE-Local : OK Eclipse Project Explorer -> RSE-Local : OK IMHO this is not yet good enough for a 1.0 release, so I'm keeping priority P2. 1. Wherever a Folder works OK, a file should also work OK; looks like the update policies are currently not ok - Windows Explorer -> RSE-Local - Eclipse Navigator -> RSE-Local 2. Wherever Copy&Paste works OK, drag&drop should also work ok and vice versa - Eclipse Project Explorer -> RSE-Local - RSE-Local -> Eclipse Navigator 3. Eclipse Project Explorer should work the same as Eclipse Navigator - RSE-Local -> Eclipse Project Explorer
Drag and drop from Windows Explorer to Local for both files and folders seem to work for me. Martin, which driver are you trying?
See comment 4 : "HEAD on 20-Sep-2006", I did the test right after our committer call and had updated the workspace before, so that was about 16.00 UTC or 12.00 Toronto time. I'd not be surprised if this bug is a regression due to the fix for bug 157719 which was checked in by Dave D two days ago. When I paste or drop a single file into the Local subsystem, the expanded/collapsed indicator besides the folder flickers a little, it looks really strange.
*** Bug 158730 has been marked as a duplicate of this bug. ***
I fixed one bug yesterday that was related to drag and drop of files and folders from windows explorer to RSE.
No additional work will be done on this now so I'm lowering the priority.
Since the Project Explorer is a default view now, this should be addressed soon.
Dave do you have a chance to look into copy&paste to Project Explorer any time soon? The Project Explorer is the Eclipse Default View since M5.
I notice with HEAD that I can neither copy&paste from Remote into the Project Explorer, nor the CDT C/C++ View (which is based on the Project Explorer), nor the good old Resource Navigator. According to comment #2, it looks like the problem in Resource Navigator is that it uses FileTransfer types for paste, which means we'd have to download on Copy already (which is not what we want). I'm wondering whether we could announce it as PluginTransfer instead, such that we can programmatically do the download after the paste operation. Pasting remote elements into user-defined local views is an important use-case, and we should fix at least the Project Explorer issue. Resource Navigator is perhaps not that important any more since it's not a default view any more.
SystemDropActionDelegate is supposed to help accomplish the dragging and dropping from rse to navigator. I wonder if there's something broken with that now.
By removing the FileTranferType support from the system views we avoid a transfer type that we stopped supporting as of going open source (because rse.ui is file-independent). This support was causing the common navigator to skip plugin transfer checking. I've also changed the SystemDropActionDelegate to handle the case where an IProjectNature is the target. This allows us to drag and drop to projects in the Project Explorer.
I've fixed up the drop action delegate to reset the target for unknown types to be the IResource we adapted to. This allows for drag and drop to source folders and packages in the Project Explorer. I still don't have this working for the Package Explorer. Package Explorer supports the following drop types: Transfer[] transfers= new Transfer[] { LocalSelectionTransfer.getInstance(), FileTransfer.getInstance()}; It doesn't, however, support PluginTransfer, which is what we do for Resource Navigator and now Project Explorer so we might not be able to do much about it.
I've renabled the drop support for FileTransfer (but not the drag support) so that drag and drop from Windows Explorer to RSE can work. RSE to Windows Explorer still won't work because we don't support the drag this way (to do so requires remote-file awareness in the generic drag adapter. We may be able to enable this by having some kind of File.class adapter for RSE objects. We'd need to know whether files are local or not. For local ones, we would be able to make use of FileTransfer, while for remote ones, we'd be faced with the dilmemma of whether to automatically download on a drag or not. Any thoughts on that?
Tested with HEAD as of 14-Mar-2007: * Drag & drop works fine now RSE -> Resource Nav and Project Explorer. * Copy & paste out of RSE does NOT work. Neither in resource navigator nor in project explorer, neither on the project target nor on a folder target. The "Paste" action just is not enabled. I think that this is very important to fix. * For copying or dragging out of LocalFileSubSystem, I believe we should make use of the FileTransfer method. This makes us more compatible, and allows people to dump remote files in local intermediately, so they can drag from RSE-Remote -> RSE-Local -> Final destination. The cost of doing some extra if() for local seems OK for this extra benefit. * For Package Explorer, I'm not worried at all. It's unlikely that people will need it, and if they do they can either create a remote EFS project or switch to the Project Explorer. I also tested the following EFS based scenario, which I found interesting: On an SSH Only connection, select a remote folder and choose right-click > Create Remote Project. This creates an EFS-backed project in the Eclipse Resource System. From this remote project, I can NOT drag&drop or copy&paste to Windows explorer - I get a dialog "Error: Cannot copy file: Cannot read from source file or disk". So this is in line with RSE not supporting drag&drop remote -> Windows Explorer. Therefore, I still think we should not automatically download on Copy or Drag. But what I can do in this scenario, is copy & paste to package explorer or resource navigator. So here, the EFS-backed scenario is better and this is another indication that we should fix RSE native copy&paste as mentioned above.
The Navigator PasteAction.updateSelection() method is described as follows: /** * The <code>PasteAction</code> implementation of this * <code>SelectionListenerAction</code> method enables this action if * a resource compatible with what is on the clipboard is selected. * * -Clipboard must have IResource or java.io.File * -Projects can always be pasted if they are open * -Workspace folder may not be copied into itself * -Files and folders may be pasted to a single selected folder in open * project or multiple selected files in the same folder */ protected boolean updateSelection(IStructuredSelection selection) That means, unless the src is an IResource or a java.io.File, paste will be disabled. The only way to get an IResource from RSE is to download it and java.io.File only makes sense for the localfilesubsystem (and to do that we'd need find a way to couple copy/paste with file subsystems). Perhaps download on "copy" would not be as much of an issue as it is on drag since it's a complete operation on it's own. What do you think?
Hm. The problem with download-on-copy is, that we'd need to wait for the operation to complete before we can allow paste. So we cannot do it in background. Or if we'd do it in background, we'd need to somehow update state of the Clipboard once it is complete. Desired behavior is to copy some meta-info only and do the actual transfer in a background job on paste. Perhaps we can address this properly soon, when the EFS support is more stable. Then, we should be able to wrap any remote file in an IResource that's backed by EFS. I did not check whether it's possible to create an IResource that's not below a current project but I think that this should be possible (Editors are able to load files outside any projects, and Debugger is able to show source for such external files). On the other hand, since we'll not get around making a local copy in order to be able and paste it to the Windows Explorer, perhaps the following is an option: - On Copy or Drag, create a local empty file in the RSE file cache - Populate the file in a background download - When the download is complete before the paste / drop action happens, we are good. If not, ... (well I'd be wondering what would happen). Seems not perfect, but probably OK for small files. And better than having nothing at all, which is the current state. Should we give that a try? Thoughts?
Created attachment 60819 [details] download during copy action patch Here's a patch to download during the copy. What do you think of this?
I've committed the patch that causes a download during the "copy" action. The same has not been done for drag but the drop action delegate gets used in that case anyway.
Since the project explorer copy/paste and drag and drop should work now, the defect described in the title should be fixed. I'd still like to look at this for windows explorer, since the copy solution should allow us to give win explorer a file path to the temp files. I'll do that in m7.
Marking fixed since Project Explorer works with M6. For Windows Explorer, discussion is continued on bug 181458.
We had to take out this fix again because of critical bug #189268. A proper fix will need the Project Explorer to support the PluginTransfer method. See bug #181458 comment 5 for an idea how the situation could be improved in RSE in the meantime, though we cannot guarantee fixing this in 2.0.1.
*** Bug 176929 has been marked as a duplicate of this bug. ***
I found a very nice write-up of how drag&drop is supposed to work in the Common Navigator / Project Explorer, in bug #195595 comment 4. This basically says that Project Explorer does support PluginTransfer, but "drops between views which only understand PluginTransfer are limited to the LocalSelectionTransfer type", if I understand it right. Dave could you also read this and let us know if that iformation might help getting drag&drop to the Project Explorer to work? If not, then perhaps what we need is a general new kind of Transfer type for deferred transfer of files that are available as Streams only. Bug #196176 requests this on behalf of dragging remote files to Windows Explorer, and I believe it is a general request needed also by Eclipse Platform to support drag & drop in any views that support EFS as their resources. We should closely watch that bug.
Drag&Drop seems to work reliably now, supposedly thanks to the fix for bug 232889. It seems that Copy&Paste just cannot work.
Tentatively targeting 3.1
It seems that there are still issues with copy and paste as well as drag and drop, at least under Linux in PHP-Explorer (Versions: eclipse galileo 3.5.1.M20090917, PDT 2.1.3.v20090914, RSE 3.1.1.v200907301400) scenario: LOCAL folder in local php-project REMOTE linked folder (per ssh) in same local php-project what is working for me is: copy and paste as well as drag and drop for files AND folders from LOCAL to REMOTE copy and paste as well as drag and drop for files from REMOTE to LOCAL what is NOT working is: copy and paste as well as drag and drop for folders! from REMOTE to LOCAL The problem is, that the remote folder is locally created but with file system rigths rw- r-- r-- so that the user cannot write to the newly created folder (umask is 0022). An error message pops up saying "Could not move rse:://hostname/..../REMOTE". Clicking Undo does'nt remove the localy created folder I have screen shots of the error messages but don't know how to attach them. By the way: Debugging with xdebug on the remote php-files doesn't work as well (the path mapping between URL and linked REMOTE folder in the local project seems not to work). But this seems to be a bug, that should be addressed to the PDT project. Never the less: thank you all for your great work
Bulk moving 3.2.x bugs to 3.3
Bulk moving 3.3 deferred items to 3.3.1
