After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 345314 - when you rename a file cursor will not stay on file
when you rename a file cursor will not stay on file
Status: RESOLVED FIXED
Product: gnome-commander
Classification: Other
Component: application
1.2.x
Other All
: Normal minor
: 1.2.5
Assigned To: epiotr
epiotr
: 396489 521063 (view as bug list)
Depends on:
Blocks:
 
 
Reported: 2006-06-19 13:19 UTC by Peter Steh
Modified: 2008-03-09 22:50 UTC
See Also:
GNOME target: ---
GNOME version: ---


Description Peter Steh 2006-06-19 13:19:08 UTC 
when you rename a file coursor will be on the file you were working with

Other information:
unfortunatelly i few times expected this behaviour and when i was working fast i accidentally deleted some files i didn't want to because coursor ended on different place than i expected.
Comment 1 Paweł Widera 2007-05-27 17:33:19 UTC 
Confirming. After rename the focus is not "sticky" to the renamed file but to the file position on the list. See example below.

List before rename (focus marked with []):
[aaa.txt]
 bbb.txt
 ccc.txt
File aaa.txt is now renamed to ddd.txt. List after rename:
[bbb.txt]
 ccc.txt
 ddd.txt

Expected behaviour after rename would be to have focus on file ddd.txt (this is how it's done by midnight-commander).

As already mentioned this "non-sticky" behaviour is very dangerous when combined with other operations like delete/move/copy, since the file on which the action is executed is a random file from the list. The same applies to directories.

Bug is still present in 1.2.3
Comment 2 Paweł Widera 2007-05-27 18:16:07 UTC 
The same problem has been also described on the mailing list:
http://lists.gnu.org/archive/html/gcmd-devel/2006-11/msg00006.html
Comment 3 André Klapper 2007-05-27 18:24:21 UTC 
*** Bug 396489 has been marked as a duplicate of this bug. ***
Comment 4 Visa-Matti Lehtimäki 2007-07-28 15:22:28 UTC 
I think this behaviour I encountered is the same as this rename bug.

1. open an archive to your archive manager by double-clicking the archive in GC.
2. extract the contents to the directory where the archive is located
3. close archive manager - your cursor in GC should visually be on the archive file you just double clicked. however, if you try renaming or deleting without clicking the correct file, you'll notice that the file that is going to be renamed or deleted is not the one your cursor seemed to be highlighting.

I lost a file by hastily doing so, and I still don't know what it was. Maybe I'll be wondering why something is missing some day..
Comment 5 epiotr 2008-01-21 12:40:48 UTC 
This problem has been fixed in our software repository. The fix will go into the next software release. Thank you for your bug report.
Comment 6 epiotr 2008-03-09 22:50:53 UTC 
*** Bug 521063 has been marked as a duplicate of this bug. ***