I accidentally ‘moved’ a ton of songs to Picard, instead of just drag n drop (copying) and they are now gone from the folder they were in. Where have they gone.
1 Like
What do you mean, moved?
What did you do with your mouse and/or keyboard, exactly?
Picard can rename files and move them to folders called by the album names…
Picard would not have moved files unless you saved them. If you saved, then they may have been moved to the directory root you set in Options.
1 Like
The same way you move files from one folder to another, select them and then hold shift down and then release the mouse button.
I was in the process of copying files (drag n drop) to picard when I accidentallt had pressed when I released the mouse button. The files were then moved to picard and removed from the folder they were in, just like files would be moved when you drag n drop them from one folder to another, while holding down.
You can not “move” files into Picard.
(You just add folders with files or selected files to Picard).
Please check, if you have Options “Move Files” activated.
If you have activated this option, additionally check
Options → Options → File naming and there “Move files when saving”
Check the destination directory where the files will be moved if you save your files inside Picard.
3 Likes
@pooky2483 Thanks for opening the ticket. For reference:
I can’t test this the next two weeks. Can someone try to reproduce this behaviour with SHIFT-dragging a file on Windows (with a copy of a file)?
Errr… and just as describe, it disappeared. (Win10, Picard v2.9 Portable version)
First I SHIFT+DRAGGED a folder. And that worked as usual and just appeared in Picard and jumped to the right as already matched.
I then opened that same folder on File Explorer, SHIFT+DRAGGED one of the tracks into the left side… and not only did it disappear from the hard disk, but now the album on the right hand side is one file down!
It is still sitting “unclustered” on the left, and the status bar it still shows the filename where it was… but the file disappeared the moment I SHIFT+dragged\dropped it
2 Likes
It seems that’s a Windows specific issue, I can’t reproduce it on Linux.
Can someone reproduce it on any other platform? Does it happen with non-portable version for Windows?
1 Like
As said before I currently cannot test this. But reading up on QDropEvent Class | Qt GUI 5.15.14 I think the following happens:
When you Shift-Drag on Windows this gets delivered to Picard as a “move action”. As Picard generally accepts move actions (because inside of Picard you can move items around between panes) it acknowledges the move, which makes Windows delete the source.
I think the fix will be to only accept a drop from outside Picard (which means as a drop without a source widget) as a “copy” action and never as a move.
Quite interesting that it took 16 years until someone identified and reported this issue. @pooky2483 thank you so much for reporting and everyone here for the investigation. We’ll get this fixed for the 2.9.1 release.
9 Likes
Yep - also happens in v2.8.5 win10 non-portable normal install… just tried it same as above. Funny how something so extreme can stay hidden for so long.
2 Likes
The actions are defined here. It looks like we will need to check the proposed action using [QDropEvent::proposedAction()], and if it is a proposed MoveAction then override it to a CopyAction using the QDropEvent::setDropAction(). I am not sure what we should do with the other actions, but probably the best would be to override all actions with Copy (with the possible exception of IgnoreAction which we should probably ignore).
1 Like
If I remember correctly MKVToolNix has a warning about this (or had) in their FAQ, this is a Windows issue (using SHIFT)
It wasn’t in the FAQ it was a Reddit post see:
https://www.reddit.com/r/mkvtoolnix/comments/lws5pv/massive_bug_deleted_hundrets_of_files_non
Just to be sure:
We are talking about the Windows File Explorer feature to press Shift (on the same hard drive) or Ctrl (for different hard drives) during the drag & drop process, right?
Shift or Ctrl which toggles between copying and moving selected files or folders to another target location and also works this way for Picard, right?
1 Like
Yes. This is about moving files using the modifier keys. You have got their definitions a little confused though.
Shift will MOVE and Ctrl will COPY.
When you drag between different hard drives the default action of drag and drop is COPY. When you drag on the same drive the default action is MOVE. This is why it is useful to know the above Shift and Ctrl commands. (And therefore easy to accidentally perform the above bug)
Also possible to use RIGHT mouse to drag the file and you’ll get the menu instead.
3 Likes
Why would you ever press a “modifier key” at all to drag & drop selected files or folders to a 3rd party software?
Do you know any software (other then Windows File Explorer) where this would be beneficial?
Could easily be done accidentally. If you are moving lots of files around and multi-tasking. Just one of many windows open on the screen.
Interestingly CTRL+Z does also work. If you spot it quick enough you can undo the action.
What I find interesting is MKVToolNix also having seen the same issue. This is likely lurking in many apps un-noticed.
It is just a standard “computer being dumb, doing exactly as told” action.
Where would it be beneficial? First places I think of are File Shredders and Encryption tools.
3 Likes
The fix for this is now in Picard 2.9.1:
1 Like