Bug 303742 - After renaming file with name exists in its folder and cancelling folder view does not updates.
Summary: After renaming file with name exists in its folder and cancelling folder view...
Status: RESOLVED FIXED
Alias: None
Product: dolphin
Classification: Applications
Component: general (show other bugs)
Version: 2.1
Platform: unspecified Linux
: NOR normal
Target Milestone: ---
Assignee: Dolphin Bug Assignee
URL:
Keywords: reproducible
: 307074 (view as bug list)
Depends on:
Blocks:
 
Reported: 2012-07-18 14:06 UTC by Melkozerov Alexander
Modified: 2012-10-31 22:07 UTC (History)
2 users (show)

See Also:
Latest Commit: http://commits.kde.org/kde-baseapps/7cff47b01254f35bf413eac5d9d336f77c6f5fd9
Version Fixed In: 4.9.3

Attachments
Work-in-progress patch (1.41 KB, patch)
2012-09-20 23:47 UTC, Frank Reininghaus 		Details
View All Add an attachment

Note You need to log in before you can comment on or make changes to this bug.
Description Melkozerov Alexander 2012-07-18 14:06:22 UTC 
I have 1 file named "3333" and 1 folder named "1231" in current folder.
I'm trying to rename file to folder's name "1231". In the dialog "name exists" I press "cancel" button. After it I see two files named "1231" until I reload (press F5) folder contents.

Reproducible: Always
Comment 1 Frank Reininghaus 2012-08-06 09:42:33 UTC 
Thanks for the bug report, I can confirm this problem. Very strange, but I hope it's not hard to fix.
Comment 2 Frank Reininghaus 2012-08-13 10:30:35 UTC 
The problem is that DolphinView::slotRoleEditingFinished() changes the file name in KFitemModel before KonqOperations::rename() (the function which does the actual renaming and shows the dialog if necessary) gets called.

I think there's no good way to find out what KonqOperations::rename() actually did. I think the best way to fix this might be to check in DolphinView::slotRoleEditingFinished() if a file with a new name is already in the model and not call KFileItemModel::setData() in that case. The dir lister should notify the model then when the renaming has happened.
Comment 3 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:20:03 UTC 
Resetting assignee to default as per bug #305719
Comment 4 Christoph Feck 2012-09-19 22:08:05 UTC 
*** Bug 307074 has been marked as a duplicate of this bug. ***
Comment 5 Frank Reininghaus 2012-09-20 23:47:08 UTC 
Created attachment 74069 [details]
Work-in-progress patch

This fixes it in principle, but leads to other problems because lots of "Already exists" dialogs pop up. Needs more work :-(
Comment 6 Emmanuel Pescosta 2012-10-29 22:17:38 UTC 
The bug only appears with inline renaming. Renaming the file with the Rename Dialog works fine for me.
Comment 7 Frank Reininghaus 2012-10-30 06:23:35 UTC 
Yes, that's because the DolphinView updates the file name only in the "Rename inline" case. When using the dialog, the file name update is done when we receive the dir lister's signal.

I think my patch from comment 5 might work fine if the "multiple signal connections/no disconnections" issue that we're discussing in https://git.reviewboard.kde.org/r/107070/ is resolved.
Comment 8 Frank Reininghaus 2012-10-31 22:07:50 UTC 
Git commit 7cff47b01254f35bf413eac5d9d336f77c6f5fd9 by Frank Reininghaus.
Committed on 31/10/2012 at 23:06.
Pushed by freininghaus into branch 'KDE/4.9'.

Do not show an incorrect file name after a failed rename operation
FIXED-IN: 4.9.3

M  +12   -3    dolphin/src/views/dolphinview.cpp

http://commits.kde.org/kde-baseapps/7cff47b01254f35bf413eac5d9d336f77c6f5fd9