This is an automatically generated e-mail. To reply, visit: http://git.revie= wboard.kde.org/r/103555/

On December 28th, 2011, 7:37 a.m., David Fa= ure wrote:

= = =

kio/kio/kdirlister.cpp (Diff revision 1)
void KDirListerCache::slotFileDirty( const QString& path )
		1078	// (read: parent) d= irectory dirty. Not the one whose permission changed.

Yes, but =
changing permissions is only one case for ending up here. The most common c=
ase is that KDirWatch (in Stat mode) notifies us that a directory has chang=
ed because files have been created in it, or deleted, etc. In that case we =
do want to make the directory as dirty, not its parent.
I guess that means we need to do both, mark the parent and the directory it=
self, as dirty. Sucks for performance, though.
The real issue is that KDirWatch's dirty() signal is pretty unspecific.

Ah, I know. This is called by KDirWatch so it's local only, no networ t=
ransparency.
So we should just clear the permissions/owner in the KFileItem for the dire=
ctory, they'll be re-determined on demand by KFileItem.

On December 28th, 2011, 4:49 p.m., Dawit Alemayehu wrote:

> Yes,=
 but changing permissions is only one case for ending up here. The most com=
mon case is that KDirWatch (in Stat mode) notifies us that a directory has =
changed > because files have been created in it, or deleted, etc. In tha=
t case we do want to make the directory as dirty, not its parent.

Yes, I got that. But when an item in a given directory is renamed, deleted =
or created, slotFileDirty is invoked with the path set to that directory an=
d not the specific file or directory that was modified. IOW if I have a dir=
ectory called "Test" that contains two items, a directory named &=
quot;New Folder" and a file named "New File.txt", then when =
either one of those two items are renamed or deleted or a third item is cre=
ated the parameter to slotFileDirty is the full path to "Test". H=
owever, if I simply touch or change permission on either one of those items=
, then the parameter to slotFileDirty is set to the full path for "Tes=
t/New Folder" or "Test/New File.txt".

Everything works fine except when you change permissions or timestamp on th=
e child directory, i.e "New Folder". In that case because the par=
ameter passed to slotFileDirty is the full path to the directory that was m=
odified, "Test/New Folder", the call to updateDirectory, called f=
rom handleDirtyDir, does nothing. Why ? The call to checkUpdate always retu=
rns false since "New Folder" is in neither itemsInUse nor itemsCa=
ched containers.

On January 2nd, 2012, 8:56 p.m., Dawit Alemayehu wrote:

@David: T=
ried this approach, i.e. calling refresh on the changed directory's KFi=
leItem if it is not in the cache, but it did not seem to work for me. I am =
sure I am doing it wrong. Here is what I changed my patch into:

if (!itemsInUse.contains(url.path()) && !itemsCached.contains(url.p=
ath())) {
    KFileItem* item =3D findByUrl(0, url);
    if (item) {
        kDebug(7004) << "*** Refreshing" << item;
        item->refresh();
        return;
    }
}

But that does not seem to work. The code path is definitely hit called beca=
use the debug statement is printed out on the command line.

Oh, I forgot to answer this (ouch, exactly a year ago already).

Your testing is based on the inotify backend. When using "stat" (=
due to no inotify support -- for instance on non-linux systems, or over NFS=
), slotFileDirty isn't emitted. All that KDirWatch can find out is that=
 "something changed inside directory <parent>".

As in your more recent patch, the condition inside the if() is wrong, the i=
f() will always pass since these contain urls, not paths.

Refreshing the item might have the problem that whichever code looks into t=
he item later on, is working on a copy. KDirLister needs to call emitRefres=
hedItems in order to let the world know about the modified item.

- David

On December 29th, 2012, 8:31 p.m., Dawit Alemayehu wrote:

Review request for kdelibs and David Faure.

By Dawit Alemayehu.

Updated Dec. 29, 2012, 8:31 p.m.

Descripti= on

If you open a directory that contains other directories in K=
onqueror or Dolphin, change the permission of one of these directories from=
 outside, say the command line, and right click on the same directory to lo=
ok at the permission tab in the properties dialog, you will see that the pe=
rmission change has not been updated. This patch addresses that bug.

Testing <= /h1>

1. In konsole, create a test directory within another test d=
irectory:
     mkdir -p test/test1

2. Open Dolphin or Konqueror and navigate to the top newly created director=
y, i.e. test.
   =

3. In konsole, cd into the first test directory:
     cd test

4. In konsole, change the permission of 'test1' from konsole. For e=
xample,
     chmod go-rx

5. In the open Dolphin or Konqueror, right click on "test1", sele=
ct properties and click on permission tab.

6. Validate whether or not the permission shown in the GUI matches what you=
 get in the command line.

Bugs: 173733

Diffs=

kio/kio/kdirlister.cpp (ec3d622)

View Diff