INTERACT FORUM

"was what I attempted dumb? " - no ive done the same, as have others...

1) from within mc just copy them back

2) select the files you want > library tools > move / copy > select COPY!

pip

I mentioned this back in the 9.1 days.  I asked why MC did a "move" when you selected "copy" from the right context menu.  I was told that the way to move files was to use the "Copy/Move" function and hit "copy" instead of "move" (which of course works), but I never got an answer as to why the right click "copy" command did a move operation instead.

I totally agree that this can be dangerous, and I don't understand why MC chose not to use the normal right click "copy" and "move" options that work according to the windows standards.

Larry

I think that happens because the file operations inside MC are in the first place intended for organizing files inside the current library. If files would copy by default you would end up with duplicates.

I think you're confusing what we're talking about with dragging and dropping, which is an entirely different subject.  I'm focusing completely on the "copy" operation you select in the right click menu.  Windows Explorer absolutely does not work the way MC does in the respect.  In Windows Explorer, "copy" means copy, and "move" means move.  Dragging and dropping operations are a separate subject.

Why would anybody NOT expect "copy" to result in duplicates -- that's the definition of "copy."  The problem with MC is that when you do a "copy" using the right click menu, you DON'T end up with duplicates, but rather with a move.  When you do a "copy" with the "copy/move" command, on the other hand, you DO end up with duplicates.  MC is not just breaking the definition of "copy" in one case, it's being inconsisant with it's own definition.

Larry

Thanks for the concern guys ... I feel loads better now , even though I still have to somehow return the files to their original locations. Since they were from a random source, they will all have to be returned to different folders ...  

As to the debate/discussion about the copy context command vs. drag'n'drop ... it seems to me that they should be identical in function and only different in the way the user activates them. Sometimes I copy & paste (keyboard shortcuts), sometimes I use the context menus and sometimes I drag. I do not know what makes the decision for me, except whether the mouse in in my hand at the time.

It has been suggested that MC does not know where the music file actually is, but a qucick check of the source and destination paths should be able to determine a change of drive, and thus the type of operation, or the need for a warning dialogue box. The issue of then having duplicate files in two locations within the same library would be no more difficult than not adding the copied files. After all, this seems to be what happens with other remote devices.

My ideal would be that dragging files to another drive would default to copy, unless the Shift key is used (ala windows); and also that the mouse pointer has a clear + added to the arrow to denote this.

I am also a fan of ACDSee. I like version 3 the best, before they bloated it with editors etc (sound familiar?). ACDSee uses a system where you can setup a series destination folders/paths that will appear in a dialogue box. You select on the context menu 'Copy to...' and a box appears displaying a range of user defined locations, plus the opportunity to add/edit/remove locations.

Ith issue about the inconsistency of the copy/move commands in different locations is incredible ... it reminds me of the debate that we had some time ago (MJ7->MJ8 ?) about glossy skin development being prioritized above basic function development. (my 7 posts implies an ardent observer who simply cannot keep up with the rate of updates)