Review Request: Fix for stale permissions information in properties dialog

[Dawit Alemayehu]

> On Dec. 28, 2011, 7:37 a.m., David Faure wrote:
> > kio/kio/kdirlister.cpp, line 1078
> > <http://git.reviewboard.kde.org/r/103555/diff/1/?file=44960#file44960line1078>
> >
> >     Yes, but changing permissions is only one case for ending up here. The most common 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 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 itself, 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 transparency.
> >     So we should just clear the permissions/owner in the KFileItem for the directory, they'll be re-determined on demand by KFileItem.

> Yes, but changing permissions is only one case for ending up here. The most common 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 that 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 and not the specific file or directory that was modified. IOW if I have a directory called "Test" that contains two items, a directory named "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 created the parameter to slotFileDirty is the full path to "Test". However, 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 "Test/New Folder" or "Test/New File.txt".

Everything works fine except when you change permissions or timestamp on the child directory, i.e "New Folder". In that case because the parameter passed to slotFileDirty is the full path to the directory that was modified, "Test/New Folder", the call to updateDirectory, called from handleDirtyDir, does nothing. Why ? The call to checkUpdate always returns false since "New Folder" is in neither itemsInUse nor itemsCached containers.


> On Dec. 28, 2011, 7:37 a.m., David Faure wrote:
> > kio/kio/kdirlister.cpp, line 1080
> > <http://git.reviewboard.kde.org/r/103555/diff/1/?file=44960#file44960line1080>
> >
> >     Well, that's equivalent to looping over url.directory() instead of url.path(), then. Which then means both cases (directory and file) can be merged.

Ahh... I do not follow.


- Dawit


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103555/#review9322
-----------------------------------------------------------


On Dec. 27, 2011, 6:26 p.m., Dawit Alemayehu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103555/
> -----------------------------------------------------------
> 
> (Updated Dec. 27, 2011, 6:26 p.m.)
> 
> 
> Review request for kdelibs and David Faure.
> 
> 
> Description
> -------
> 
> If you open a directory that contains other directories in Konqueror or Dolphin, change the permission of one of these directories from outside, say the command line, and right click on the same directory to look at the permission tab in the properties dialog, you will see that the permission change has not been updated. This patch addresses that bug.
> 
> 
> This addresses bug 173733.
>     http://bugs.kde.org/show_bug.cgi?id=173733
> 
> 
> Diffs
> -----
> 
>   kio/kio/kdirlister.cpp ec3d622 
> 
> Diff: http://git.reviewboard.kde.org/r/103555/diff/diff
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Dawit Alemayehu
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20111228/2f4dc12c/attachment.htm>