Community
Participate
Working Groups
On an SSH connection, I want to copy a large folder tree from one location to another. But select the source, right-click > copy already starts downloading thousands of files in thousands of jobs. Marking as Critical since I have no chance canceling all these jobs except quit Eclipse. I did not want to download anything but do a plain remote-to-remote copy only. I think that the impact of "download on copy" is just too severe and does not justify the (small) improvement made for bug #181458. -----------Enter bugs above this line----------- TM 2.0RC1 Testing installation : eclipse-platform-3.3M6 (I20070323-1616), cdt-4.0M5, emf-2.3M5 RSE install : download RSE 2.0RC1 runtime-all + terminal java.runtime : Sun 1.6.0-b105 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Linux-ssh (dstore-processes) targetos : SUSE Linux Enterprise Server 10 (ppc) targetuname : Linux build 2.6.16.27-0.9-ppc64 #1 SMP ppc64 GNU/Linux targetvm : ibm-java2-sdk-5.0-0-4.0-linux-ppc ------------------------------------------------
Martin, you already agreed that you wanted copy to work for windows explorer and now apparently you're changing you mind on this. If you want to change your mind of this then you realize we're going to be regressing all of that work.
With an ssh connection to build.eclipse.org (reasonably slow), I tried this: 1. Select remote *.tgz archive 30MB large, right-click > Copy Select Windows folder, right-click > paste --> File is created with 272KB size only. No error message about truncated file. 2. While The "Download-due-to-copy" was still ongoing, drag&drop another 30MB file to the windows explorer folder --> All of Eclipse freezes, no UI updates any more, my session is dead. My debugger shows this backtrace on the main thread: Thread [main] (Suspended) Object.wait(long) line: not available [native method] Channel$MyPipedInputStream(PipedInputStream).read() line: 310 Channel$MyPipedInputStream(PipedInputStream).read(byte[], int, int) line: 361 ChannelSftp._get(String, OutputStream, SftpProgressMonitor, int, long) line: not available ChannelSftp.get(String, String, SftpProgressMonitor, int) line: not available SftpFileService.download(String, String, File, boolean, String, IProgressMonitor) line: 531 FileServiceSubSystem.download(IRemoteFile, String, String, IProgressMonitor) line: 446 SystemEditableRemoteFile.doDownload(SystemIFileProperties, IProgressMonitor) line: 608 SystemEditableRemoteFile.download(IProgressMonitor) line: 587 LazyDownloadJob.run(IProgressMonitor) line: 36 SystemViewDataDragAdapter.getResource(IAdaptable) line: 378 SystemViewDataDragAdapter.dragSetData(DragSourceEvent) line: 244 DNDListener.handleEvent(Event) line: 54 EventTable.sendEvent(Event) line: 66 DragSource(Widget).sendEvent(Event) line: 938 DragSource(Widget).sendEvent(int, Event, boolean) line: 962 DragSource(Widget).sendEvent(int, Event) line: 947 DragSource(Widget).notifyListeners(int, Event) line: 706 DragSource.GetData(int, int) line: 411 DragSource.access$7(DragSource, int, int) line: 390 DragSource$4.method3(int[]) line: 252 COMObject.callback3(int[]) line: 92 COM.DoDragDrop(int, int, int, int[]) line: not available [native method] DragSource.drag(Event) line: 322 DragSource.access$0(DragSource, Event) line: 282 DragSource$1.handleEvent(Event) line: 166 EventTable.sendEvent(Event) line: 66 Tree(Widget).sendEvent(Event) line: 938 Display.runDeferredEvents() line: 3673 Display.readAndDispatch() line: 3284 Workbench.runEventLoop(Window$IExceptionHandler, Display) line: 2389 Workbench.runUI() line: 2353 Workbench.access$4(Workbench) line: 2219 Workbench$4.run() line: 466 Realm.runWithDefault(Realm, Runnable) line: 289 Workbench.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 461 PlatformUI.createAndRunWorkbench(Display, WorkbenchAdvisor) line: 149 IDEApplication.start(IApplicationContext) line: 106 EclipseAppHandle.run(Object) line: 153 EclipseAppLauncher.runApplication(Object) line: 106 EclipseAppLauncher.start(Object) line: 76 EclipseStarter.run(Object) line: 363 EclipseStarter.run(String[], Runnable) line: 176 NativeMethodAccessorImpl.invoke0(Method, Object, Object[]) line: not available [native method] NativeMethodAccessorImpl.invoke(Object, Object[]) line: 39 DelegatingMethodAccessorImpl.invoke(Object, Object[]) line: 25 Method.invoke(Object, Object...) line: 597 Main.invokeFramework(String[], URL[]) line: 497 Main.basicRun(String[]) line: 436 Main.run(String[]) line: 1162 Main.main(String[]) line: 1137 For me personally, these two experiences are sufficient to ask for backing out the "download-on-copy" change since it has really REALLY bad effects. Imagine somebody dragging & dropping a file to win.explorer and then deleting the remote copy because he thinks it's been transferred properly -- data will be lost. I'd rather not have the copy-remote-to-windows-explorer feature than risking such problems. For the future, we'll need to work with the Platform to improve SWT drag&drop support to Win.Explorer and Project Explorer.
Created attachment 69304 [details] patch to avoid downloading on copy to clipboard This patch backs out the download we do on copy. There should be another one for drag and drop.
The drag and drop portion of this only occurs during FileTransfer (i.e. transfer to windows explorer)..but nevertheless, it can be problemmatic for large files so I'll have to take that out.
Created attachment 69323 [details] complete patch for avoiding copy Here is the complete patch, addressing copy and drag and drop. To avoid drag and drop logic that does copy, we need to get rid of the FileTransfer type on drag.
Hm, this patch looks much smaller than expected :-) In Lines 93-111, I actually do not see any difference. I approve the patch but have one question: does this patch also disable FileTransfer for the "Local" subsystem? I think it should be working there if possible. Another idea I had in order to accomodate some of the improvements we are losing with backing this out completely is in bug #181458 comment 5.
When verifying this, the other issue (drag&drop on the Display thread) also needs to be verified.
The getResource() call is only made when we're supporting resource transfer (i.e. download on copy). I'm not sure whehter we should be treating local different or not because, under normal RSE behaviour we treat it like any remote subsystem, copying (or downloading) the files to the temp file cache. I can see why it would be okay to skip that step but I worry about inconsistencies.
I've committed the changes for this.
[target cleanup] 2.0 RC2 was the original target milestone for this bug
