Renaming Bug in Thunar

Bug #1311926 reported by slumbergod on 2014-04-23
48
This bug affects 10 people
Affects Status Importance Assigned to Milestone
thunar (Ubuntu)
High
Unassigned

Bug Description

This is a strange behaviour which has been present for a while but is still happening in xubuntu 14.04's thunar. I am sure it can't be a feature.

To replicate:
-----------------
Using the Detailed View in thunar navigate to a folder with lots of files.
Rename one where its position in the list will change (e.g. "0.nametotop" will go to the top of the list).
Upon pressing enter, the file is moved and remains highlighted as the currently selected file.
Now press down to move to the file directly below its new location in the list.
Instead of moving down one place, the selection suddenly jumps to where the file used to be before it was renamed
(i.e. the file pointer has not been updated to reflect the location of the file after naming).

A similar issue happens with the shortcuts pane on the left.
If you middle click over a shortcut to open the location in a new thunar window, the entry is highlighted as the current location but the contents in the main pane remain the same. Middle clicking on a shortcut should not highlight the shortcut name.

ProblemType: Bug
DistroRelease: Ubuntu 14.04
Package: thunar 1.6.3-1ubuntu5
ProcVersionSignature: Ubuntu 3.13.0-24.46-generic 3.13.9
Uname: Linux 3.13.0-24-generic x86_64
ApportVersion: 2.14.1-0ubuntu3
Architecture: amd64
CurrentDesktop: XFCE
Date: Thu Apr 24 11:43:07 2014
EcryptfsInUse: Yes
InstallationDate: Installed on 2014-04-18 (5 days ago)
InstallationMedia: Xubuntu 14.04 LTS "Trusty Tahr" - Release amd64 (20140414)
SourcePackage: thunar
UpgradeStatus: No upgrade log present (probably fresh install)

slumbergod (slumbergod) wrote :
Launchpad Janitor (janitor) wrote :

Status changed to 'Confirmed' because the bug affects multiple users.

Changed in thunar (Ubuntu):
status: New → Confirmed
Paul White (paulw2u) wrote :

Using the version of Thunar in https://launchpad.net/~xubuntu-dev/+archive/ubuntu/xubuntu-staging for 16.04 I don't think I see this as described in the Bug Description. The highlighting of the renamed file is usually correct but in about 10% of renamings the wrong file is highlighted.

What I am seeing is this:

1) Using six files in a directory I rename one to something like 00.txt.
2) It moves to the top of the list
3) I rename it to zz.txt and it moves to the end of the list but
4) The highlighted file is the fifth in the list
5) If I rename it to ff.txt it moves to its correct position
6) Another rename to zz.txt moves it to the end of the list but this time the correct file is highlighted.
7) After several more renamings which appear to work correctly I rename the file zz.txt and it moves to the end
8) But the last but one file is highlighted so the wrong file being highlighted is not consistent.

Using the latest daily build of 16.04 (20160408) I'm seeing something very similar, possibly not exactly the same due to different file names used in the test.

tags: added: xenial
Changed in thunar (Ubuntu):
importance: Undecided → High
Ubuntu QA Website (ubuntuqa) wrote :

This bug has been reported on the Ubuntu ISO testing tracker.

A list of all reports related to this bug can be found here:
http://iso.qa.ubuntu.com/qatracker/reports/bugs/1311926

tags: added: iso-testing
Thomas Schweikle (tps) wrote :

There is a fix released for this bug upstream. Seems this Bug is there even a year ago …

Angger B. Pinasti (anggerbp) wrote :

same as #3 kind of... better but not fixed. it has 10% chance, and we got no clue visually wether this 10% is trigered or not (we don't want to always see the file properties before we do something with the file, do we?). I have mistakenly delete wrong important file for few times because of this.

Also I experienced the chance is bigger if the file size is bigger, and I let the window open when editing the file. i.e, big png/gimp and big svg/inkscape. After saving, visually the file position wasn't changed, but in fact it's not the right file.

Also kind of wondering what was those refresh button for? :) Because if I go to the parent folder and entering the corresponding folder again, the representation get updated, just like the refresh button should do...

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers