GP SoftwareTwitter
Opus FAQsManualCommandsObjects

RDP Copy&Paste creates new files/folders


#1

Hello you! o)

If I copy (ctrl+c) a folder on my local machine, and paste it (ctrl+v) into DO running on the remote computer (through the RDP-Window), DO creates a new folder named like “FolderName (1)” and also new files with the same naming-pattern for all the files contained in the folder. The files though renamed, go into the right (existing) folder at least, the folder “FolderName (1)” remains empty.

Doing copy and paste operations entirely on the remote computer within the RDP session and DO behaves normally. Doing a local copy and remote paste with Explorer only, also works as expected.

My local machine is a Win7Prox64, the destination opened in the RDP window is a WinSrv2012R2.
It does not make a difference if “ask for confirmation before merging existing folders” is enabled or not.

Any hints appreciated! Thx! o)

This happens for single files which are copied and pasted like described as well, btw.
Existing files will not be overwritten, the pasted files will be renamed to “File (1).ext”.


#2

I can’t reproduce this.

Is your ctrl-v or ctrl-c/x hotkey on either machine running anything non-standard?


#3

I nearly use RDP daily between different machines, no probs (except when using Teamviewer, DO shows an error when pasting things).


#4

I have same problem
I am using windows 8.1 on both pc
I am using dopus 11.12.4B
I select file and connected to remote PC
pasted via Context menu
a number of log files , all have pasted get (1) after name name
next paste have (2)


Sven Åke


#5

That’s normal, if you paste a file that already exists the second copy will get a number on the end to make its name unique.


#6

so what you say is that if I copy/past from local to remote
is NOT same as copy on RDP from folder to folder (in this case it’s ask if I will replace files)
so paste means 2 different things depending on what source is used?

Sven Åke


#7

It’s nothing to do with RDP - it’s the normal behaviour of the Clipboard Paste command to bump the filename if a file of that name already exists. Using the Copy Files button or drag & drop is different - that runs the Copy command which will prompt to overwrite.


#8

Misunderstood tbone’s initial post, so yes, if file/folder already exists, file/folder gets numbered.

But Jon, in Explorer you’ll be asked to overwrtite exitsing files/folders when copying from remote Explorer to local Explorer or vice versa.


#9

Edit: With “copying” I meant using clipboard/c’n’p of course.


#10

if you copy past local in same directory it will be named file-kopia.txt
and after that it will be file-kopia(2)(kopia is in Swedish för copy)
in RDP it’s file(1).txt
so NO it’s not same in RDP and local copy, at least gives 2 different names

Sven Åke


#11

@leo
No, there’s nothing “non-standard” on cltr-c/v - it’s just Clipboard COPY and PASTE.

@all
I think we need to differentiate between copying a folder or file and then pasting it right back to the same location, or copying & pasting something between different locations, that uses the same name.
In the first case, you always get a “* - Copy (x)”, in the second, DO normally asks what to do (merge/overwrite folders/files?).

Now my problem is, that I try to copy the folder “D:\CopyMe” from my local machine to the remote machine to drive C:, where a folder “CopyMe” already exists. I’d expect DO to ask what to do, but this is what I end up with:



The difference in the name, after a copy&paste from/to the same folder: “* - Copy (x)” vs. “* (x)”
…is probably another topic, but noticably at least for RDP copy/pastes.


#12

In my original reply above, I didn’t realise we were talking about pasting things that already exist in the destination. I thought these folders were appearing out of nowhere.

I see the same thing, in that case, when using Remote Desktop. I suspect this also happens with other clipboard sources which put virtual files into the clipboard, rather than pointers to real files. That is likely behind the difference in behavior compared to local files. (Whether or not it should be different is another matter.)


#13

Well, when using Explorer for the same “copy-local” / “paste-remote” operation, it asks what to do and I’d guess most people expect that to work in the same way when using DO - at least my collegues and I do. o) But as a general first result, I’m just glad you can reproduce it.

Btw: If you “remote-copy” with Explorer in the RDP window and “local-paste” with DO, the described behaviour is exactly the same (renamed folders will be created instead of a merge(-confirmation)), so this maybe can be reduced to DO behaving strange when reading/pasting the clipboard filled by rdpclip.exe/mstsc.exe?


#14

This is a pretty old thread, but there seems to have been no resolution for this problem.

If I copy/paste 100 files from our production servers (accessed via RDP) and I paste them locally, there appears no way to overwrite the files. It makes no sense to me that the explanation is that the files in the clipboard are "virtual". Dopus should ask me what I want to do, not make an assumption based on the kind of file that's on the clipboard. At this point I have to create a temp directory, paste the 100 files, then cut them and paste them where they need to go. That's really annoying (especially when I forget that it's going to happen and get 100 renumbered files).

Has anyone found a solution to this problem?


#15

I usually use network shares to copy things between machines I'm connecting to via RDP, assuming one side can see a share on the other to the file you need.

The remote desktop client can also automatically make one or more local drives available in the remote session when it connects, if there aren't shares already set up.


#16

We'll change how this works in the next update, so that you'll be prompted to replace the existing file or rename the new one.


#17

Hooray! People using DO at work will send you postcards! o). It really helps if DO can be used to copy & paste files directly into/from the remote system just as Explorer does. Thank you! o)

There might be untrusted domains/network resolving issues and other things which prevent you from using UNC or the automatically mapped drive (thinking about MS Azure here). Different credentials needed each time and how windows stores these (or not) is another pain in the rear. So the most easy thing, to cut & paste directly, is very often the last option you have. No more need to switch over to Explorer is very welcome! o)