Bug 389892 - A file can go into a weird superposition state "being moved while being renamed", which causes an unrelated file to be renamed to the file just moved
Summary: A file can go into a weird superposition state "being moved while being renam...
Status: RESOLVED DUPLICATE of bug 378786
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 17.12.1
Platform: Fedora RPMs Linux
: NOR major
Target Milestone: ---
Assignee: Dolphin Bug Assignee
Depends on:
Reported: 2018-02-04 21:25 UTC by David Tonhofer
Modified: 2018-03-29 19:21 UTC (History)
2 users (show)

See Also:
Latest Commit:
Version Fixed In:


Note You need to log in before you can comment on or make changes to this bug.
Description David Tonhofer 2018-02-04 21:25:03 UTC
I have an occasional bug whereby the following happens:

A file (foo.pdf, say) in directory A is moved to directory B using Dolphin.

This move succeeds but an unrelated file (stuff.txt, say) in directory A then takes on the name "foo.pdf".

This happens occasionally and I haven't been able to reproduce this reliably. It's extremely annoying though.

Is there a way to switch on some kind of "action trace" of Dolphin?
Comment 1 David Tonhofer 2018-02-04 21:40:45 UTC
Special configuration of my mouse:

Activating windows Policy = "Focus Follows Mouse"
Comment 2 David Tonhofer 2018-02-04 21:46:38 UTC
It happened again.

I am using Dolphin in "split window" mode when moving files from one directory to the other (from right to left, say)

I have the feeling that it has something to do with a file having the "renaming action" active on the right side. You then move that file to the left side, which works but the renaming action on the right side is "sticky" and gloms onto the file that was displayed underneath the one just moved, giving it the name of the file just moved. Something like that.
Comment 3 David Tonhofer 2018-02-17 17:25:08 UTC
Better reproducible:

1) Have a directory of many files.
2) Create a target directory that is linked to via the Dolphin "left pane" (the left pane where you find like the Wastebasket, Search For, Devices etc).
3) The Mouse Click behaviour is set to "Double click to open files and folders" (Sysetm Settings > Input Devices > Mouse) (because I still haven't found out how one can actually DO anything at all if a file opens on first click)
4) Do this:

   Click on a file in the Dolphin main pane, release Mouse.
   The file is selected.
   Move the file into the target directory in the "left pane"
   With high probability (1/5?), a file or even a directory in the "from"
   directory takes on the filename of the file just moved.

Moving this to "major" as this will result in file loss.
Comment 4 David Tonhofer 2018-03-04 22:38:21 UTC
Even more precise:

The problem comes from the fact that somehow renaming is triggered on the file.

Suppose the file in details view mode is unmarked (it may be semi-marked, there is a thin blue line underneath, not 100% sure what this is about, my reflexes don't tell me).

Click on it, it acquires a blue background.

Release mouse, move off the file.


a) Move mouse back to file, click and don't release button, hold it.

b) The file will go into "rename mode" after 500ms or so, after which it cannot be moved.

However in some cases:

a) Move mouse back to file, click and don't release button, move it to the left-side "Places bar" for example.

b) Sometimes the file while go into "rename mode" while you move it. If you now drop it into a "place", the file underneath the just moved file in the "details view" will be given the name of the file just moved. 

I don't know what exactly triggers the quantum state of "being moved" + "being renamed" at the same time, but the state machine seems to have a bug in any case.
Comment 5 Christoph Feck 2018-03-29 17:18:58 UTC
You are using double-click to open files, right? If this issue happens to you regularily, I suggest to disable inline renaming in Dolphin.
Comment 6 Nate Graham 2018-03-29 19:21:40 UTC
This has been fixed in Dolphin 18.04.

*** This bug has been marked as a duplicate of bug 378786 ***