problem with KIO::NetAccess and KDirLister/KFileTreeView

[Josef Weidendorfer]

Followup:

KIO::DeleteJob does it right: stops dir watching - deletes files - restarts 
dir watching - and tells the world about deleted files (With KDirNotify).

The last action should trigger a refresh in KFileTreeView.
Don't know why this doesn't happen.

And the API of KDirWatch is fine as long as we start the refresh after
restoring the watch ;-)

Josef


On Tuesday 08 October 2002 15:45, Josef Weidendorfer wrote:
> Hi,
>
> I think I found the problem:
>
> See documentation of KDirWatch::restartDirScan():
>
>    /**
>     * Restarts scanning for specified path.
>     *
>     * Resets ctime. It doesn't notify
>     * the change (by emitted a signal), since the ctime value is reset.
>     *
>     * Call it when you are finished with big operations on that path,
>     * @em and when @em you have refreshed that path.  Returns @p false
>     * if specified path is not in list, @p true otherwise.
>     */
>    bool restartDirScan(const QString& path);
>
> Pending events are deleted - on purpose - and since ages. This
> documentation is from dsweet on 2000/6/25. I never changed any semantics.
>
> So KIO::DeleteJob is using KDirWatch the wrong way: The path contents
> should be refreshed. This never was right.
>
> On the other side: This API is nonsense. If the path is to be refreshed
> before calling restartDirScan(), we always can miss an event happening
> after the refresh but before the restartDirScan() call.
> Fix: Never delete pending events and let the refresh happen in response to
> signals from KDirWatch: To keep BC, I suggest adding a
>   bool restartDirScan(const QString& path, bool clearPending);
> and mark the old one as obsolete. If you look at the implementation of
> restartDirScan, this is quite easy.
>
> Can the above race condition happen with KDirLister in general?
> I.e. does it read in the directory content before setting a watch?
>
> Josef
>
> On Tuesday 08 October 2002 14:26, Klaas Freitag wrote:
> > On Tue, 8 Oct 2002, David Faure wrote:
> > > I guess this is done by KDirLister (which sort of "quits" the dir, and
> > > then "re-enters" it). Some kdBacktrace() investigation by Klaas would
> > > help ;)
> >
> > Hmmm. Investigation is the wrong word here, but I can attach a file
> > showing the context of start- and stop scanning, renaming starts at line
> > 627 to see in the logfile.  For me it seems as if the delete event
> > arrives first and makes KDirWatch stop scanning (line 645) with
> > stopDirScan. The following backtrace in the log is printed in the next
> > line of kdirwatch. The restart follows immediately by
> > restartEntryScanDir. For me, the log shows that the 'here is a new file'
> > signal does not appear. Hmmm. I hope you see what happens :-)
> >
> > Klaas