I often use a program called Link Shell Extension to easily create and manipulate junctions and symbolic links in windows, and DO seems to behave correctly when moving a junction that is located on the same drive (ie. when you cut/drag a junction into a new folder, it moves the junction as a junction). However, when the junction being moved/cut+pasted has a target located on a different drive (ie. a junction on the C drive that points to a folder on the D drive) then DO insists on making a copy of the contents of the target directory, rather than simply recreating/moving the junction.
Is this a bug? ... and if it isn't, is there a way to achieve the desired behavior of having junctions remain junctions when they are moved (instead of having dopus do a recursive copy of the contents of the target directory).
FWIW, you can create them using Opus as well, via Copy MAKELINK and similar commands.
That is standard behaviour. Moving a file between devices is done via a copy-then-delete, and there's no way to be sure that creating a junction instead of a copy on the target device would make sense. (e.g. The target device may be about to be moved to another computer, or the source device may be about to be decommissioned.)
If you link your account then we'll put a method to do this on our list for consideration for a future version.
Since my last symbolic link issue got resolved, I thought I'd resurrect this thread again, and add some more information to clarify what I think the original poster meant.
If you have a symbolic link C:\foo\link.txt to C:\foo\baz.txt and drag link.txt to C:\bar, then the default action (Move) moves the link.txt to C:\bar, and the alternate action (Copy) copies baz.txt to C:\bar.
However, if you have a symbolic link C:\spam\link.txt to D:\eggs\ham.txt and drag link.txt to C:\parrot then the default action (Copy) copies ham.txt to C:\parrot, and the alternate action (Move) deletes link.txt in addition to copying ham.txt to C:\parrot.
In short, the behavior is different depending on whether a symbolic link points to a target on the same drive or not. It appears to be using the target of the link to determine whether source and destination are on the same volume and thus whether it can simply rename the link. Presumably this applies to junctions and directory symbolic links as well.
When dragging a group of links and files, the first file selected (that is, in display order, not the order it was added to the selection) dictates whether the group gets renamed or copied. So if the first file is a normal file, all the files and links get renamed into the new directory.