Editing after renaming a file does not update preview and saves as previous filename
Closed, ResolvedPublic


When a file is renamed and then saved it is saved with the previous filename. Additionally, since commit afbad38a6de7a519a4aeabba42f8b48cdc2e3d4c the preview does not update with the new edited image(but still edits the original image).

Reproduction steps:

  1. Open image a.jpg
  2. Rename image to b.jpg (F2)
  3. Edit it (Ctrl+L )
    1. Since afbad38a6de7a519a4aeabba42f8b48cdc2e3d4c the preview does not update
  4. Save (Ctrl+S)
  5. In all versions (from at least tag v17.08.3) now both a.jpg and b.jpg exist where the original filename (a.jpg) is the edited one.

So before afbad38a6de7a519a4aeabba42f8b48cdc2e3d4c both the selected image and the current url was incorrect (not updated), while after that commit the selected image is correct, but everything depending on currentUrl (editing, saving, full screen label, saveBar, ...) still gets the wrong image.

One contextManager->setCurrentUrl(newUrl) after the rename would make sure both are up to date.

slenz created this task.Feb 24 2018, 8:26 PM

We still use Bugzilla to track bugs and small tasks; see https://community.kde.org/Infrastructure/Phabricator

We generally only use Phabricator tasks to coordinate multi-part tasks that will require a lot of individual patches. See for example T7841: Revamp buttons on the bottom to solve various usability issues or T7958: Adopt Kirigami ToolBarApplicationHeader

If this doesn't meet that criteria, please close it and file a Bugzilla ticket.

@ngraham No, it's alright. Read D10745#212824, where I was under the impression this would turn into a huge investigation needing coordination via a task. Thankfully it did not.

@slenz Thanks, your investigation was amazing, and the fix so simple! You can add Closes T8071 to the summary of D10745, then Phabricator will close this task on commit.