Community
Participate
Working Groups
Download the dstore host zip for Windows, and unzip it. Ran setup.bat and daemon.bat. Create a Windows DStore connection. Copy a folder and paste to another folder (already been expanded). The Transfer Operation dialog came up and progress is Copying. It just kept running, and workbench hang. I also ask Kevin to try, and he got the same problem. -----------Enter bugs above this line----------- TM 2.0RC1 Testing installation : eclipse-platform-3.3M7 (I20070503-1400) RSE install : RSE-SDK-2.0RC1.zip java.runtime : Sun 1.5.0_06-b05 os.name: : Windows XP 5.1, Service Pack 2 ------------------------------------------------ systemtype : Windows - DStore
There is no problem using DStore Linux. The linux machine we tried (SLES8RM) has the RC1 dstore driver installed.
Actually, this problem exists in M7 driver. I just tried using RSE-SDK-I20070524-0915.zip with rseserver-2.0M7-windows.zip, and could reproduce it.
The problem is on the server side. I could see the client is waiting on the server for the result of DStore command: at org.eclipse.rse.services.dstore.util.DStoreStatusMonitor.waitForUpdate(DStoreStatusMonitor.java:343) at org.eclipse.rse.services.dstore.util.DStoreStatusMonitor.waitForUpdate(DStoreStatusMonitor.java:249) at org.eclipse.rse.services.dstore.AbstractDStoreService.dsQueryCommand(AbstractDStoreService.java:147) at org.eclipse.rse.internal.services.dstore.files.DStoreFileService.getFile(DStoreFileService.java:732) at org.eclipse.rse.subsystems.files.core.servicesubsystem.FileServiceSubSystem.getFile(FileServiceSubSystem.java:298) at org.eclipse.rse.subsystems.files.core.servicesubsystem.FileServiceSubSystem.getRemoteFileObject(FileServiceSubSystem.java:141) at org.eclipse.rse.internal.files.ui.view.SystemViewRemoteFileAdapter.doDrop(SystemViewRemoteFileAdapter.java:1995) at org.eclipse.rse.internal.ui.view.SystemDNDTransferRunnable.transferRSEResources(SystemDNDTransferRunnable.java:254) at org.eclipse.rse.internal.ui.view.SystemDNDTransferRunnable.runInWorkspace(SystemDNDTransferRunnable.java:575) at org.eclipse.core.internal.resources.InternalWorkspaceJob.run(InternalWorkspaceJob.java:38) at org.eclipse.core.internal.jobs.Worker.run(Worker.java:58)
Xuan, you had been looking at this and said there was something to do with the xcopy command used. Could you please comment about that here?
Scenario: I copied the folder d:\tmp\mydummy (which contains file "epdcdump01.hex12" and "epdcdump01.hex13"), and right click on folder d:\tmp\aaacc (which already has file "epdcdump01.hex12"), and choose Paste. The Copy operation kept on going. After debugging, I could see this is the command used in UniversalFileSystemMiner#doCopyCommand (which is called by UniversalFileSystemMiner#handleCopyBatch()) xcopy "D:\\tmp\\mydummy" "D:\\tmp\\aaaacc" /S /E /K /Q /H /I which is incorrect. If we want to copy the folder (which means create the folder "mydummy" inside "aaaacc") using xcopy command, it should be something like: xcopy "D:\\tmp\\mydummy" "D:\\tmp\\aaaacc\mydummy" /S /E /K /Q /H /I What command xcopy "D:\\tmp\\mydummy" "D:\\tmp\\aaaacc" /S /E /K /Q /H /I does is to copy all the files inside "mydummy" folder into "aaaacc" folder. Since there is already a file called "epdcdump01.hex12" inside "aaaacc", the command is actually prompt for user input to overwrite the existing one. That is the reason that the copy operation is hanging. The "/Y" option for xcopy handles suppresses prompting to confirm overwriting, but we only used it in the case of copying file, not folder.
I tried the local case, and this is the command used in LocalFileService.copy(): xcopy "D:\\tmp\\mydummy" "D:\\tmp\\aaaaccc\\mydummy" /S /E /K /Q /H /I So local connection handler this case correctly. But local connect also has its problem for copying folder: I tried the following in the RC1 driver for local connection: I have a folder call dummy1, which contains three files: epdcdump01.hex12 epdcdump01.hex13a epdcdump01.hex13b And I also have another dummy1 folder inside my d:\tmp\xuan, which contains the following files: epdcdump01.hex12 epdcdump01.hex13 So I copied the dummy1 which contains three files, and pasted on d:\tmp\xuan. I got a dialog for file name conflict, and I chosed overwrite. Then I got the Copying Transfer Operation kept on going.
I also tried the case for copy/paste multiple folders using Windows DStore: If I copy two folders, and paste to a destination folder, this is the command I got: xcopy "D:\\tmp\\aaaab" "D:\\tmp\\aaaabb" "D:\\tmp\\xuan" /S /E /K /Q /H /I I tried execute this command (change "\\" to "\") in my DOS prompt, and I got Invalid number of parameters 0 File(s) copied Does xcopy handle multiple source folders with separated names?
Also there is some consideration for case where the target folder already has a folder of the same name. xcopy command just copied the files in the source folder to the target folder. It does not (I tried some combination of xcopy, and did not see a way) replace the existing folder. So we probably need to remove the existing folder first, and then do an xcopy to truely implement the overwrite request from the user. I almost think that we need to write a separate method to handle copy/paste in Windows DStore.
Bug 189979 has been opened specific for Copy/Paste conflict folder problem for Windows - Local connection.
(In reply to comment #8) In Windows explorer, when you drag&drop a folder into a hierarchy where that folder already exists, it also merges the old contents with the new one, overwriting only files that exist in both folders. I think that UNIX cp -R also works like this. I think that users are accustomed to this kind of operation so I don't see a need for deleting the folder upfront or doing other special handling. The only thing that we REALLY need to make sure is that xcopy doesn't go and ask for user interaction (which would cause the hang we've experienced). So, I'm not sure if that other bug is actually needed.
Ok, the only problem with Windows Local is that it needs a "/Y" in its xcopy command. It should be easy to fix.
I just took a look at the LocalFileService#copyBatch method: public boolean copyBatch(String[] srcParents, String[] srcNames, String tgtParent, IProgressMonitor monitor) throws SystemMessageException { boolean ok = true; for (int i = 0; i < srcParents.length; i++) { ok = ok && copy(srcParents[i], srcNames[i], tgtParent, srcNames[i], monitor); } return ok; } So for each source,it uses a separate copy() method to handle it, which means using a separate xcopy command. I think we should do the similar for DStore, at least for Windows. Please comment. Thanks.
Could you supply your changes as a patch? Thanks.
Created attachment 69367 [details] fixes for copy/paste for Windows (DStore and Local) I put in the following fixes: LocalFileService: Add "/Y" at the end of xcopy command if has not include it yet UniversalFileSystemMiner#handleCopy() . For Windows, we always append the source name to the end of target folder UniversalFileSystemMiner#handleCopyBatch() . For Windows, we call doCopyCommand() separately for each source folder. . Also need to append the source name to the end of the target folder. UniversalFileSystemMiner#doCopyCommand() . Add "/Y" to the end of the xcopy command for folder. 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.
Created attachment 69383 [details] updated patch since file has been change in between. 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 committed the patch but just waiting for Kushal to review.
*** Bug 189979 has been marked as a duplicate of this bug. ***
Since the patch is applied, I'm marking this as fixed.
This problem has been fixed in 2.0 RC4 driver.
[target cleanup] 2.0 RC2 was the original target milestone for this bug
