problem with KIO::NetAccess and KDirLister/KFileTreeView

[Josef Weidendorfer]

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