Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Folbo]

I wanted to copy a random selection of music to my laptop, over my network, so that I can listen to some music whilst at work....

Easy I thought, from a random playlist drag the files to my the drive on the network ....

Problem .... the files were moved not copied!!!!! I cannot believe that the default action is to move files (contrary to the default explorer action which is what your tree structure appear to emulate)

was what I attempted dumb? or is the default action dumber (note there is no warning/cancel when moving files from one physical place to another... not so much as a warniong or are you sure...)

Question 1
How do I put the files back?

Question 2
How do I copy files in the future? (I can do it to my SD card for my palm automatically)

[pipsqueak]

"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

[gpvillamil]

I've noticed how dangerous this is. Even the Move/Copy dialog is potentially awkward, if you hit the wrong button.

I really think MC should prompt before doing something that is potentially so destructive of a library.

[lalittle]

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

[Alex B]

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.

In a way Windows Explorer behaves similarly. If you drag files inside the same disk (partition) they will move. Only when you are dragging files to another disk you make copies. You can transfer this philosophy to MC if you replace the word "disk" with the word "library".

MC has no way to know that when the files are dragged to a networked disk the intention is not to change physical location in the current library.

You could first collect the files to a playlist (named e.g. "notebook") and then copy them all at once by Tools>Library Tools>Move/Copy Disk File.

[lalittle]

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

[Alex B]

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.

I answerred to the first post. Folbo wrote about dragging:

...from a random playlist drag the files to my the drive on the network ....

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.

Yes, you are right. At first I had hard time to figure out what do you mean, because there is no "copy" directly in the right click menu. I have never paid attention to the "Edit" there. Probably I thought that it would lead to editing files in the Media Editor. I have always gone from right click menu to "Library Tools>Move/Copy Disk File".

When I am in the Drives & Devices and "right click>edit>copy" a file in E:\test\ (the path includes many files in my library) and then "right click>edit>paste" in D:\destination (not yet in library) it certainly moves. On the other hand, after the operation both paths exists in my library and there would be a duplicate if the operation was a "copy/paste" as we usually understand that. I like to have duplicates in my playlists, but not in the main library.

I don't think there is anything wrong with how the edit>copy/paste works in this case. Those commands should just be renamed.

How ever, when I am in the main library and do "right click>edit>copy" for a file in E:\test\ and try to "right click>edit>paste" to D:\music\ nothing happens. A bug?

When doing that in the Playlists or in the Playing Now it seems to do a copy/paste, so you can duplicate items there.

Alex

[Folbo]

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)

[Alex B]

How about these:

- Copy Disk File to a destination outside of the library...

- Copy Disk File to a new location and keep all files in the library (makes duplicates)...

- Move Disk File (keep in the library)...

- Move Disk File (remove from the library)...

instead of "copy & paste" in the Edit menu and the "Library Tools>Move/Copy Disk File".


Besides that there should be a "copy & paste" for tags, text, playlist entries, etc as before.


Edit: On a second thought, it's quite complicated because there are so many ways to do those things. Every possible combination should be considered before making changes to the logic.

But maybe something like those commands would reduce confusion.