Hi.
Somehow I accidentally changed a setting and now I cannot replace existing folders/files as desired.
In my example (see image) ...
I meant to replace the database folder and files with my drag-drop of the database folder from another window. Instead it creates ...well, look at the image.
I'm at a loss as for what settings to look for that controls this activity.
Actually, I'm cutting and pasting from an rdp window.
I just verified it works with windows explorer and I'm sure it always worked with dopus prevously
as I never use anything else.
Do you think it's settings related? Is there an unattended default action setting somewhere?
Ok. I've done some more testing.
Seems to be only when I copy from and rdp window and paste into a folder with the purpose of overwriting any existing folders.
Let me know if you want me to do any other tests.
...happy to help.
If it's from an RDP Window then it'll be pasting "virtual" files, where all the information about the files, including the data they contain, is streamed in memory from the source program (the RDP client in this case).
That's different to normal, where the pasted data points to some real files somewhere which are then copied.
When virtual files are pasted it can cause Opus to behave differently, although I couldn't tell you the exact rules off the top of my head. That difference probably explains why you've seen a change in results. Presumably the things you were copying & pasting before were normal files and folders from another window on the same machine.
Yes, I believe you are correct. I do have lots of windows open (local vmware, rdp, dopus, rdp (with vmware in them)).
I do a lot of cutting/pasting. I just assumed (albeit incorrectly) that it worked in dopus. I was probably pasting from a local vmware guest when I said that it worked previously. My apologies for this.
I understand your "virtual file" brief explanation. Is there any way this could be addressed in an upcoming release?
...to behave as it does in a native window explorer?
Has this been addressed in any fashion?
I just upgraded to the latest release (12.3.1 BETA) and it seems as though it is behaving as this post dictates, add-in a (#) to the file. I do not recall this behavior in 12.3 itself. I looked for a setting but was unable to find anything and wanted to validate what is expected behavior.
In an RDP session copy one or more files to the clipboard. Locate a folder on my local machine in directory opus and paste the files. For any file(s) that exist it does not prompt to overwrite but instead adds another copy with the number in the name.
OK, that is normal at the moment, and has always worked that way. Copy and paste across RDP boundaries does not copy & paste real files, but virtual file streams, which trigger different behavior.
If you use a network share (UNC path or mapped drive) to copy the files, that will behave normally as it works on the real files.