Log a message when changing filenames to avoid conflicts

[alch-emi]

Summary

When moving an item with the move command, if a file that's not registered with beets exists in the destination directory, beets gives the file a unique filename, but neglects to tell the user that the move didn't go as planned (even if in verbose mode), and continues to claim that the file was moved if the command is run again, even if the file isn't moved. If the command is run with the -p flag in order to cause a dry run, beets claims that it is moving the file to the original file name, not the unique-ified name.

Setup

• OS: Linux 4.16.5-1-ARCH
• Python version: Python 3.6.5
• beets version: 1.4.6 [no plugins; default options]

Reproduction

1. With an empty library, import an item.
2. Change the library directory in the config to point to a new, empty directory.
3. Create a dummy file in the new directory mirroring the actual music file. For example, if the real file is in library/DummyArtist/DummyAlbum/DummySong.mp3, and your dummy library is newlibrary, create the file in newlibrary/DummyArtist/DummyAlbum/DummySong.mp3. The content is irrelevant. It can be identical, empty, or corrupt.
4. Issue beet -vv move -p. Notice that beets declares that it is moving the song to the same location as the dummy file, and doesn't mention any problem with this
5. Issue beet -vv move. Beets moves the item to newlibrary/DummyArtist/DummyAlbum/DummySong.1.mp3, and doesn't mention it, even with verbose mode enabled.
6. Issue beet -vv move -p and beet -vv move again. In both cases, beets claims that it is moving the file, despite not moving the file at all.

Expected / Suggested Behavior

I understand why beets is doing what it is doing, but I believe that leaving the user in the dark about it can only cause confusion. I would suggest that beets do one of the following instead:

• On a move conflict, provide a dialog to the user, allowing them to choose, to skip the file, overwrite it, or use a unique name. This would essentially force the user to make a decision and enable them to deal with it easily, from withing the beets interface. It might get a little annoying if the user wants the behavior in the third bullet, or without options to assume an answer (e.g. overwrite all)
• On a move conflict, print a warning to console specifying where the error occurred. This is the closest to what beets currently does, and seems like a simple solution that gives the most control to the user without being too silent or interrupting an otherwise one-click action. If the user wants to deal with the problem themselves, however, they need to manually remove the conflicting item, which might be annoying if there are hundreds of conflicts
• If the file is already in the location it would be moved to (but not where it should be), don't list the file as being moved by the move command. This would allow users who don't care what goes on in their beets directory as long as it works to go on with life without knowing that there was a problem, as opposed to having potentially hundreds of false move messages when consolidating their libraries

Notes

I encountered this problem while attempting to deal with #2747. I accidentally ran beet import -A $mylibrary without the flag to import as singletons, and because of the way my paths were set up, and some commands attempting to fix this issued with a poor understanding of how Beets works, ended up with my entire library duplicated in this way. My specific situation might be uncommon, but I imagine that the ability to deal with conflicts in general might be useful.

[sampsyo]

Thanks! I like the idea of logging a message in verbose mode, at least, when these renamings need to occur. That should probably be the first milestone (and might be a little trickier than it seems), and then we can explore more direct ways of informing the user.