renamer is copying the video if the video is locked
Describe the bug If a video file is locked (in Windows) (e.g. a mkv is played in VLC) then the renamer is (slowly) copying it. After the copy is finished the new copied file(s) is deleted and the rename is showed as failed.
To Reproduce Steps to reproduce the behavior:
- play the mkv in VLC (Windows)
- use the renamer
- check in windows explorer that a new file with a the new name is created and is slowly growing and is deleted after it reaches the size of the original.
- rename shows the file as rename failed.
Expected behavior renamer should fail "immediately" if a file is locked. How is it implemented? As a move? Maybe a rename is fitting better.
Screenshots na
MediaElch Version:
- [x] 2.12.0 (stable)
Operating System:
- [x ] Windows
- [ ] macOS
- [ ] Linux (distribution: .)
Oh, wow!
Thank you very much for reporting this issue!
Please note that, due to limited time, I can't say when or if I will get to work on this issue.. See https://github.com/Komet/MediaElch/issues/1710 for details.
Regards,
Andre
Please note that, due to limited time, I can't say when or if I will get to work on this issue.. See #1710 for details.
Got it.
Seems to be an "intended" behaviour of QT,
QFile Class | Qt Core | Qt 6.9.0 https://doc.qt.io/qt-6/qfile.html#rename
"... If the rename operation fails, Qt will attempt to copy this file's contents to newName, and then remove this file, keeping only newName. If that copy operation fails or this file can't be removed, the destination file newName is removed to restore the old state. ..."
The question is, are they aware, it can also happens if the file is in use by another application?
Does the cpp implementation acts in the same way?
"... If the rename operation fails, Qt will attempt to copy this file's contents to newName, and then remove this file, keeping only newName. If that copy operation fails or this file can't be removed, the destination file newName is removed to restore the old state. ..."
Thanks for investigating! Wow, that's definitely not behavior I would expect.
Maybe we can check if the file is writable first.