To reproduce create 2 new folder: foo and bar now rename foo to bar. since bar already exists the dialog will suggest to rename foo to something else. Rename to bar1.. Now you have a new folder called bar1 and foo is still around.
Bug seems to be in the desktop KIO slave. This had a bunch of changes since 5.10 in porting.
ForwardingSlaveBase also had some changes :/ What's happening is we're doing a copy (already a bit weird, as our KIO supports renaming) and somehow the source URL is getting lost. We then come to delete the directory and try deleting QUrl() 18:16:04.228 kf5.kio.core.copyjob: KIO::CopyJobPrivate::statCurrentSrc fast path! found info about QUrl("desktop:/foo") in KCoreDirLister 18:16:04.228 KIO::CopyJobPrivate::sourceStated sources stated QUrl("desktop:/foo") "/home/david/Desktop//foo" true 18:16:04.228 KIO::CopyJobPrivate::sourceStated srcurl is now QUrl("desktop:/foo") 18:16:04.228 kf5.kio.core.copyjob: KIO::CopyJobPrivate::addCopyInfoFromUDSEntry fileName= "foo" url= QUrl("") 18:16:04.228 kf5.kio.core.copyjob: KIO::CopyJobPrivate::addCopyInfoFromUDSEntry uSource= QUrl("") uDest(1)= QUrl("file:///home/david/Desktop/ppp") 18:16:04.228 kf5.kio.core.copyjob: KIO::CopyJobPrivate::addCopyInfoFromUDSEntry uDest(2)= QUrl("file:///home/david/Desktop/ppp") 18:16:04.228 kf5.kio.core.copyjob: KIO::CopyJobPrivate::addCopyInfoFromUDSEntry QUrl("") -> QUrl("file:///home/david/Desktop/ppp") 18:16:04.228 kf5.kio.core.copyjob: KIO::CopyJobPrivate::sourceStated Source is a directory On that last line the first QUrl() is the source. This is the directly we delete after the copy finishes, and unsurprisingly that fails. 18:02:48.275 kf5.kio.core: KIO::SimpleJobPrivate::simpleJobInit|KIO::SimpleJob::SimpleJob|?libKF5KIOCore.so.5? Invalid URL: QUrl("")
I recall Kai making changes. Adding to CC.
Bug 380897 may be the same regression.
it seems info.uSource getting lost in CopyJobPrivate::addCopyInfoFromUDSEntry() that is set to url on L679.. and this is NULL at this point when I read that code right. Also uSource should point to m_currentSrcURL which is the url we want to move and remove later. Also a quick test here showed that setting info.uSource to m_currentSrcURL makes things working again but since I don't fully understand this code please have a closer look . With my local changes I get : kf5.kio.core.copyjob: fast path! found info about QUrl("desktop:/t") in KCoreDirLister kf5.kio.core.copyjob: fileName= "t" url= QUrl("") kf5.kio.core.copyjob: uSource= QUrl("desktop:/t") uDest(1)= QUrl("file:///home/crazy/Schreibtisch/zz") kf5.kio.core.copyjob: uDest(2)= QUrl("file:///home/crazy/Schreibtisch/zz") kf5.kio.core.copyjob: QUrl("desktop:/t") -> QUrl("file:///home/crazy/Schreibtisch/zz") kf5.kio.core.copyjob: GAB(6): m_mode == CopyJob::Move kf5.kio.core.copyjob: GAB(6): About to add info.uSource= QUrl("desktop:/t") to dirsToRemove.append()
const QString urlStr = entry.stringValue(KIO::UDSEntry::UDS_URL); <-- always NULL but why ? QUrl url; if (!urlStr.isEmpty()) { url = QUrl(urlStr); } ^ handles just the case urlStr exists .. else NULL ? .... code to handle all oder cases ... ... info.uSource = url; <-- NULL sice strUrl = NULL from here on stuff starts to break ... It is still to complicate for me to fully understand , sorry =) The Question is why entry.stringValue(KIO::UDSEntry::UDS_URL) is alyways NULL and also why the case urlStr.isEmpty() is not handled .. ( probably bc the code assumes entry.stringValue(KIO::UDSEntry::UDS_URL) can't be NULL ? ) Also there are some places with entry.stringValue(KIO::UDSEntry::UDS_URL) in kio code. I guess we should change the bug to KIO.. maybe David Faure has some more clue on what is going on here.?
Agreed, moving.
Git commit 6ca0b93e6029dc53a09e9e498e509ba714c2a1d7 by Eike Hein. Committed on 30/06/2017 at 06:43. Pushed by hein into branch 'master'. Use KIO::rename instead of KIO::moveAs in setData Summary: We've recently been plagued by issues where renaming via KDirModel would fail to call into the rename() implementation of kio_desktop (which is a KIO::ForwardingSlaveBase). Instead it would end up doing a copy job on its own, resulting in file removal + addition events, causing us to ultimately lose icon positions on the desktop. While I did work out why this happens through moveAs (it resolves to local URLs and then does a direct rename on them, bypassing SimpleJob calling into the slave), I failed to find anything wrong with it, leaving the reasons for the behavior change as a mystery for now: It's possible that fixes done to kio_desktop (e.g. 6911541421dc in plasma- workspace) or porting away from kdelibs4support (f81c843dcfb3, same repo) triggered it in some way in concert with KIO changes (super- ficial bisecting didn't yield anything, though). Meanwhile, this patch ports setData from moveAs to rename, which uses SimpleJob directly, successfully calling into the slave (which we really really want to do, as only the slave will trigger the right KDirNotify change signals, avoiding a row remove+insert transaction pair in the model). This makes sense to me regardless of the behavior issue with moveAs. While rename doesn't work across destination, setData operates on a single model index, and only on the file name, so this can't happen anyway, making rename the semantically correct call to make. Related: bug 380897 Reviewers: #frameworks, dfaure, davidedmundson Tags: #frameworks Differential Revision: https://phabricator.kde.org/D6413 M +2 -2 src/widgets/kdirmodel.cpp https://commits.kde.org/kio/6ca0b93e6029dc53a09e9e498e509ba714c2a1d7