Bug 374075

Summary:	File does not appear in Dolphin after creation in home folder
Product:	[Frameworks and Libraries] frameworks-kcoreaddons	Reporter:	Vadim Kolchev <vadimkolchev>
Component:	general	Assignee:	Michael Pyne <mpyne>
Status:	RESOLVED FIXED
Severity:	major	CC:	dflogeras2, elvis.angelaccio, kdelibs-bugs, r.weclawski
Priority:	NOR
Version:	5.34.0
Target Milestone:	---
Platform:	openSUSE
OS:	Linux
Latest Commit:	https://commits.kde.org/kcoreaddons/792680d43877efbea7c2367bab564e41da98be45	Version Fixed In:	5.35
Sentry Crash Report:

Description Vadim Kolchev 2016-12-23 11:08:02 UTC

Hello, noticed a problem with 16.12.0 dolphin,

Use openSUSE tumbleweed. 

How to reproduce:
1) create any text file with using of right-click - Create - Text file.
2) input name of file and press ok
3) file is not there visually

Nevertheless, file itself has been created. The way to check - via cli, or by closing and re-opening Dolphin. The file appears after that.

Comment 1 Elvis Angelaccio 2016-12-23 18:59:14 UTC

Thanks for the bug report. After some investigation, turns out that you can reproduce it only if you start Dolphin from the Plasma menu or from a Konsole _not_ in the home folder.

Otherwise if Konsole's cd is another folder, everything works as expected (indeed I could not reproduce with my local Dolphin build run from the build directory...).

Btw the problem is that the dir lister does not emit completed() and thus DolphinView::updateViewState() is not called.

Comment 2 Robert Węcławski 2017-04-11 22:24:17 UTC

I can confirm that this problem exists with 16.12.3 on KDE Neon.

This bug only occurs when I open Dolphin from Plasma menu and try to create a new text file in home folder. 

When I create file with any other type in home folder or create text file in different folder the bug does not occur.

Comment 3 Elvis Angelaccio 2017-05-13 15:53:27 UTC

*** Bug 379743 has been marked as a duplicate of this bug. ***

Comment 4 Elvis Angelaccio 2017-05-14 13:23:54 UTC

(In reply to Elvis Angelaccio from comment #1)

> Btw the problem is that the dir lister does not emit completed()

...because KDirWatch::self() does not emit the dirty() signal for "/home/user" and KCoreDirListerCache::slotFileDirty doesn't get called.

I think the bug might be in KDirWatch, kdirwatch.cpp receives the CREATE signal for "/home/user" but for some reason does not append "/home/user" to e->m_pendingFileChanges.

Comment 5 Elvis Angelaccio 2017-05-21 20:00:04 UTC

Git commit 792680d43877efbea7c2367bab564e41da98be45 by Elvis Angelaccio.
Committed on 21/05/2017 at 19:59.
Pushed by elvisangelaccio into branch 'master'.

Do not watch QRC's paths

Watching a QRC path is not supported and results in `"."` being
watched which can lead to problems.

For example in bug #374075 KIO adds ":/kio5/newfile-templates"
as path to watch (this is probably another bug in itself).
If we are already watching "/home/user", this breaks the emission
of the dirty() signal for every new children of "/home/user" (somehow,
the relative path is used for them, e.g. "./foo.txt" instead of
"/home/user/foo.txt"). In particular, in inotifyEventReceived()
e->m_client is empty and so e->path is not added to
e->m_pendingFileChanges. This only happens if "/home/user" is also
the cwd of the process using KDirWatch.

Ignoring QRC paths fixes this issue.
FIXED-IN: 5.35

Test Plan:
>From dolphin, Create New -> Text File in a folder which is also the current working
directory of the dolphin process.

Reviewers: dfaure

Differential Revision: https://phabricator.kde.org/D5877

M  +24   -0    autotests/kdirwatch_unittest.cpp
M  +4    -0    src/lib/io/kdirwatch.cpp

https://commits.kde.org/kcoreaddons/792680d43877efbea7c2367bab564e41da98be45