drag file on desktop not copy but cut

The behaviour described in the bug report is either by design, or would be far too complex/time-consuming to be changed

Moderators: Hacker, petermad, Stefan2, white

Post Reply
User avatar
dindog
Senior Member
Senior Member
Posts: 316
Joined: 2010-10-18, 07:41 UTC

drag file on desktop not copy but cut

Post by *dindog »

When I try to drag&drop a file on desktop, it move it, TC should always copy it, right?
8.0beta9
User avatar
MVV
Power Member
Power Member
Posts: 8711
Joined: 2008-08-03, 12:51 UTC
Location: Russian Federation

Post by *MVV »

Drag and drop has a rule: target window controls how it will accept files (via copy or move). In your case target window is Explorer window (desktop), so Explorer controls drag mode (move if from same drive letter and copy if between different ones).
User avatar
karlchen
Power Member
Power Member
Posts: 4605
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen »

Hm, technically the explanation is correct. Yet, knowing the default behaviour of drag'n'drop (no shift key pressed) in Total Commander is copying, it is unexpected at best that the file is moved to the desktop. (Good to know you can press Ctrl-Z in Explorer to undo this move operation.)

It gets even more confusing:
  1. T.C. is not maximized so that your original Windows is visible partially.
    You drag a file from a T.C. file panel on the genuine Windows desktop.

    Result:
    The file is moved there. Provided the original file was located on the same drive as the Windows desktop folder.
    (This is what has been reported by dindong and explained by MVV.)
  2. If you open the dektop in one of T.C. file panels by navigating there with the help of the breadcrumb bar, T.C. displays that you are inside \\Desktop.
    Now drag'n'drop a file from the opposite file panel to \\Desktop.

    Result:
    The file is copied to \\Desktop in any case. Never moved.
Suggestion:
If feasible in any way, Total Commander should make sure that drag'n'drop (no shift key pressed) will always copy.
Maybe this can be achieved by explicitly a "copy" flag? So that even if the drop target is outside Total Commander's control the drop target learns that the drag'n' drop goal is "copying".

Personally I have never really noticed the inconsistency for two reasons:
+ I do not put objects on my desktop (mission "clean desktop" :wink: )
+ I hardly ever drag'n'drop. Mice are so unprecise compared to <F5>/<F6> (motto "keyboard rulez")


Karl
Bartusg
Junior Member
Junior Member
Posts: 34
Joined: 2010-12-11, 22:17 UTC

Post by *Bartusg »

Exceptions all over, for when I drop a file (mouse button only) to the Explorer desktop's recycle bin it is moved there, even when dragged from another drive. At least this one makes sense.
I think the easiest solution would be an option for TC to behave like Explorer -or find a registry setting that would change the Explorer behavior...
User avatar
karlchen
Power Member
Power Member
Posts: 4605
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen »

Bartusg wrote:Exceptions all over, for when I drop a file (mouse button only) to the Explorer desktop's recycle bin it is moved there, even when dragged from another drive.
Well, this is not really true.

What you see in Windows as one single recycle bin are in fact separate recycle bin folders, one per local drive.
Windows will move a file living on drive C: and being deleted to the recycle bin to the recycle bin folder on drive C:.
Windows will move a file living on drive D: and being deleted to the recycle bin to the recycle bin folder on drive D:.
Windows will move a file living on drive E: and being deleted to the recycle bin to the recycle bin folder on drive E:.
etc pp
So moving to the recycle bin never crosses drive borders.
The recycle bin folder which you see in Windows is a virtual folder visually joining all existing recycle bin folders.

The Windows desktop, however, only exists once per user: It is a virtual folder visually joining the content of the physical folders "%ALLUSERSPROFILE%\Desktop" and "%USERPROFILE%\Desktop".

As a consequence, moving to the Windows recycle bin and moving to the Windows desktop are technically two different things.

Imitating the inconsistent Explorer behaviour is not really a very logical approach: Here on this machine where I am typing right now, the virtual desktop folder, consisting of "%ALLUSERSPROFILE%\Desktop" and "%USERPROFILE%\Desktop", has got one little peculiarity:
The physical folders "%ALLUSERSPROFILE%\Desktop" and "%USERPROFILE%\Desktop" are located on two different drives. Now try to predict when drag'n'drop to the Windows desktop will copy and when it will move in Explorer! :wink:

Karl
User avatar
ghisler(Author)
Site Admin
Site Admin
Posts: 50532
Joined: 2003-02-04, 09:46 UTC
Location: Switzerland
Contact:

Post by *ghisler(Author) »

Yes, unfortunately the target controls the copy or move method. TC has unfortunately no influence on it.
Author of Total Commander
https://www.ghisler.com
User avatar
karlchen
Power Member
Power Member
Posts: 4605
Joined: 2003-02-06, 22:23 UTC
Location: Germany

Post by *karlchen »

Hello, Christian.

I see. So we will have to live with it.
Yet, the average user will not put the blame on the drop target (Windows Exploer in the given example), but on the drag source (Total Commander) as this thread proves. :(

Kind regards,
Karl
Bartusg
Junior Member
Junior Member
Posts: 34
Joined: 2010-12-11, 22:17 UTC

Post by *Bartusg »

Thanks karlchen for clarifying the recycle-bin locations; turns out I do indeed have such a folder on my d:\ drive but I put it in the ignore-list and have forgotten it since.
TC imitating Explorer would not end all inconsistencies, but it would be a choice for those that use both programs.
Again, Explorer imitating TC would be cool.
Post Reply