D25732: Add only canonical paths to dirWatcher

David Faure noreply at phabricator.kde.org
Sat Dec 14 11:39:55 GMT 2019


dfaure accepted this revision.
dfaure added a comment.
This revision is now accepted and ready to land.


  Thanks for your well thought-out reply.
  The usual solution to 1. and 2. is rather "call canonicalFilePath, and if the return value is empty, use the original path". We do this in many places. But indeed this means, if a non-existing dir gets created later, it won't be canonicalized. But that's not worse than the current situation, and not an issue for the problem at hand (different use case, could be fixed in KDirWatch if needed one day).
  
  You are very correct about 3, resolving in two places is slow. This is the usual problem with shifting responsibilities around...
  
  I did some archeology, and KDirLister needs to keep a mapping because kdirwatch needs canonical paths while the model (upon receiving notifications of changes) only understands the paths as initially given (with symlinks). On hindsight, maybe I should have moved that one level down. It would be convenient for all KDirWatch users if KDirWatch itself would do this mapping, making things transparent for users of KDirWatch. You ask to watch X, you get notifications about X.
  
  So I consider the "cleanest solution, in an ideal world" to implement such a mapping in KDirWatch, and remove it from KCoreDirLister (to avoid doing it twice).
  However I can see how this is a much more involved change than what is proposed here, which continues in the same direction as what was already done, resolving in the callers of KDirWatch. So I'll accept it.
  It would be nice if someone did the right thing in KDirWatch though, so we can avoid N applications hitting this problem separately and all of them having to implement workarounds :-)

REPOSITORY
  R318 Dolphin

BRANCH
  add_only_canonical_paths_to_dirwatcher

REVISION DETAIL
  https://phabricator.kde.org/D25732

To: hoffmannrobert, dfaure, #dolphin
Cc: kfm-devel, pberestov, iasensio, fprice, MrPepe, fbampaloukas, alexde, Codezela, feverfew, meven, spoorun, navarromorales, firef, ngraham, andrebarros, emmanuelp, mikesomov
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.kde.org/mailman/private/kfm-devel/attachments/20191214/60b06a8f/attachment.htm>


More information about the kfm-devel mailing list