Drag & drop from 2 drives mounted in folders performs move

Discussion of bugs and problems found in Altap Salamander. In your reports, please be as descriptive as possible, and report one incident per report. Do not post crash reports here, send us the generated bug report by email instead, please.
Maxime
Translator
Translator
Posts: 14
Joined: 29 Apr 2006, 17:49
Location: Lyon, France
Contact:

Drag & drop from 2 drives mounted in folders performs move

Post by Maxime » 10 Aug 2015, 23:45

Hello,

Do you sometimes work with drives mounted into folders?
Very handy when you're running out of drive letters.

I have 8 drives mounted in a single parent directory: E:\Disks, containing E:\Disks\M0, E:\Disks\M1... through M7, each M* folder corresponding to a physical HDD.

In this situation, I just found that dragging & dropping files/folders from one mount directory to another (e.g. E:\Disks\M1\File1.ts to E:\Disks\M2) performs a MOVE operation, not a COPY operation, as you'd expect when doing so between two physical drives.
Simply because Salamander mistakenly thinks that I'm moving stuff from the same drive (E:), which isn't the case ;)

Could you please look at this issue? I just lost several hours backuping a drive to another, by mistakenly (but logically) thinking that moving folders from M2 to M7 would copy the contents, not move them!
(I'm now performing the same operation on the other way, with a formal Copy and Paste operation this time).

Thanks for your consideration ;)

therube
Posts: 626
Joined: 14 Dec 2006, 06:22

Re: Drag & drop from 2 drives mounted in folders performs mo

Post by therube » 11 Aug 2015, 16:23

Does Windows Explorer do differently?

In Salamander, does holding the Ctrl key down during the drag&drop effect a copy?
WinXP Pro SP3 or Win7 x86 | SS 2.54

Maxime
Translator
Translator
Posts: 14
Joined: 29 Apr 2006, 17:49
Location: Lyon, France
Contact:

Re: Drag & drop from 2 drives mounted in folders performs mo

Post by Maxime » 18 Aug 2015, 23:05

Sorry for the late reply, I had no use of my external drives until today :)

I just checked on Windows Explorer, and you're right, it behaves the same way: drag & dropping a file between two folder-mounted drives performs a move operation.
If I hold down a Ctrl key, a copy is performed instead, with both Explorer and Salamander.

So, I guess this is "normal" situation.
Anyway, I find this rather disturbing, not to say time consuming, when working with very large (several gigabytes) files.
If you intend to make a copy (like you'd expect when doing so between two letter-identified drives), performing a move with the same drag & drop operation will force you to copy the file back to its original source.

I'd not be against a little option to switch this behavior in Salamander, rather than strictly sticking to Windows Explorer's (bad) habits.
Just like you made the (very smart) choice to keep the files selected using Shift key when moving to another item using the arrow keys. I sticked to Salamander just because of this feature ;)
So, you can consider this topic as a feature request... even if I'm sure that I may be the only one actually needing it ;)

User avatar
SvA
Posts: 458
Joined: 29 Mar 2006, 02:41
Location: DE

Re: Drag & drop from 2 drives mounted in folders performs mo

Post by SvA » 19 Aug 2015, 01:51

Hi Maxime,

Even though I see and understand your thoughts and expectations, I think Windows is doing the right thing in this situation. Seen from Explorer's UI, there is nothing to tell the user that (if) two folders are on two different volumes. So, the user will expect consistent behavior. The user can tell that there are (probably) two different volumes involved, if the two paths do have different roots (Drive letters or network shares). On the flip side, Windows defaults to copy even if one "drive" is a subst to a folder on the same drive, or two shares actually are on the same volume. So the user can predict what explorer will do even without knowing the underlying (hidden) hardware structure.

In my view, the decision to copy or move depending on source and target was a wrong decision to begin with. In order to give a consistent user experience, they should have copied always when no modifier was used, and moved always with Ctrl as a modifier.

Post Reply