Bug 294445

Summary:	Renaming currently viewed folder in Folders sidebar doesn't update main area
Product:	[Applications] dolphin	Reporter:	karl.r.ernst
Component:	panels: folders	Assignee:	Dolphin Bug Assignee <dolphin-bugs-null>
Status:	RESOLVED FIXED
Severity:	normal	CC:	emmanuelpescosta099, faure, frank78ac
Priority:	NOR	Keywords:	reproducible
Version:	2.0
Target Milestone:	---
Platform:	Gentoo Packages
OS:	Linux
Latest Commit:	http://commits.kde.org/kdelibs/8141788c819fa0bcfba7cfaca474095ca819a130	Version Fixed In:	4.9.5
Attachments:	Proposed KDirLister unit test

Description karl.r.ernst 2012-02-19 19:05:20 UTC

Version:           2.0 (using KDE 4.8.0) 
OS:                Linux

Copying files into the open view after the current folder got renamed fails with access denied error

Reproducible: Always

Steps to Reproduce:
1. open any folder
2. use the folder sidebar to rename that one
3. try to drag a file (from desktop or another dolphin window, etc.) into the white area of the main view thing

Actual Results:  
Error: Access denied, can't write into folder <old folder name>

Expected Results:  
file should be copied into the renamed folder

tested with symbol view

Comment 1 Frank Reininghaus 2012-02-21 22:46:39 UTC

Thanks, I could reproduce the issue.

Comment 2 Jeroen van Meeuwen (Kolab Systems) 2012-08-24 16:18:31 UTC

Resetting assignee to default as per bug #305719

Comment 3 Emmanuel Pescosta 2012-10-27 12:55:06 UTC

Review-request: https://git.reviewboard.kde.org/r/107070/

Comment 4 Frank Reininghaus 2012-11-24 16:55:18 UTC

Created attachment 75453 [details]
Proposed KDirLister unit test

Emmanuel found out (see discussion in the review request) that the root cause of this bug is apparently that KDirLister::rootItem() does not return a KFileItem corresponding to the new view URL after the rename operation. This is a unit test for KDirLister which demonstrates this.

Comment 5 Emmanuel Pescosta 2012-12-19 00:14:58 UTC

(In reply to comment #4)
> Created attachment 75453 [details]
> Proposed KDirLister unit test
> 
> Emmanuel found out (see discussion in the review request) that the root
> cause of this bug is apparently that KDirLister::rootItem() does not return
> a KFileItem corresponding to the new view URL after the rename operation.
> This is a unit test for KDirLister which demonstrates this.

Any updates about KDirLister::rootItem() fix?

Comment 6 Frank Reininghaus 2012-12-21 15:55:21 UTC

I thought again about your earlier idea to use "m_model->fileItem(destUrl);" to determine the KFileItem for the drop target:

https://git.reviewboard.kde.org/r/107070/diff/2/#index_header

This will just make the destItem a null KFileItem if something is dropped in the empty space in the view (note that the KFileItemModel does actually not contain a KFileItem for its own URL). This means that the checks in

QString DragAndDropHelper::dropUrls(const KFileItem& destItem, const KUrl& destUrl, QDropEvent* event)

are circumvented and KonqOperations::doDrop is called directly. The problem is that you can then actually drop items in folders which you can't write to (you will get an error dialog from KIO), or you can drag a folder from the Folders Panel and drop it in itself (which fails silently).

So I would prefer to have this fixed in KDirLister, or we have to find another kind of workaround.

Comment 7 David Faure 2012-12-21 20:05:22 UTC

Git commit 8141788c819fa0bcfba7cfaca474095ca819a130 by David Faure.
Committed on 21/12/2012 at 21:06.
Pushed by dfaure into branch 'KDE/4.9'.

Fix KDirLister's rootItem not being updated when renaming the directory.

The root item kept having the old URL.

Thanks to Emmanuel for the bug investigation, and to Frank for the unittest!
FIXED-IN: 4.9.5

M  +4    -1    kio/kio/kdirlister.cpp
M  +27   -0    kio/tests/kdirlistertest.cpp
M  +1    -0    kio/tests/kdirlistertest.h

http://commits.kde.org/kdelibs/8141788c819fa0bcfba7cfaca474095ca819a130