When using "Copy to" or "Move to", Gwenview displays a file picker that asks for a filename. Whatever the entered filename is, the file will be copied/moved retaining the original filename. If the target filename already exists, the file picker will prompt to confirm that the file will be overwritten, but that is not the case. Steps to reproduce: 1. Open file a.jpg 2. Copy file a.jpg to folder/b.jpg Expected: folder/ contains b.jpg Actual: folder/ contains a.jpg
Thanks for reporting, can confirm the bug. It's a regression introduced by 9056aa941e0d which was not caught during review – sorry for that. We'll fix it for 17.12.1.
Git commit 119ac4186e4150467f4c3833d8756345b4a95191 by Henrik Fehlauer. Committed on 07/01/2018 at 23:41. Pushed by rkflx into branch 'Applications/17.12'. Respect custom filename for Copy/Move/Link To operations In `copyMoveOrLink`, 9056aa941e0d needed to strip the filename from `destUrl`. However, this was done before the actual file operation had been started, resulting in those being performed using the new target directory, but with the old filename instead of a user-provided new filename. This regression can be fixed by moving the stripping after starting the KIO job, because setting a new `targetUrl` in `contextManager` will only be needed at a later point, i.e. when persisting this path to the config. FIXED-IN: 17.12.1 Test Plan: {nav File > Copy To}, enter custom filename, verify image is copied to new path with new filename. Operations on multiple images still work, as well as remembering the last used target directory in both cases. M +5 -4 app/fileoperations.cpp https://commits.kde.org/gwenview/119ac4186e4150467f4c3833d8756345b4a95191