D25732: Add only canonical paths to dirWatcher

Robert Hoffmann noreply at phabricator.kde.org
Fri Dec 6 11:01:58 GMT 2019


hoffmannrobert added a comment.


  In D25732#573058 <https://phabricator.kde.org/D25732#573058>, @dfaure wrote:
  
  > This should go into KDirWatch itself then, to avoid the risk of other callers falling into that trap.
  
  
  I'm not sure, if that's a good idea.
  
  1. It's legal to add non-existing directories to KDirWatch. Calling QFileInfo::canonicalFilePath() on such a dir would return an empty string for it.
  
  2. Ok, you could check if it exists before canonicalizing it, but it still could be a path containing symlinks, so you need to know what you are doing anyway, when adding something to KDirWatch.
  
  3. In other places (e.g. KIO KCoreDirLister), paths added to KDirWatch are already canonicalized. Adding the QFileInfo::canonicalFilePath() call to KDirWatch would result in doing this operation twice.
  
    But initializing a QFileInfo and especially calling canonicalFilePath() are quite expensive operations. On locally mounted network paths these operations can take several seconds if the network is slow, for example when using a laptop with a VPN connection. Clicking through a directory tree can be a tedious task if you have to wait ages until the next dir level is shown.
  
    Because of this, at our LiMux project in Munich we don't use QFileInfo::canonicalFilePath() on locally mounted netshares paths (cifs, no symlinks), but an own fast method which resolves the symlinks in the users' netshares directories to the mounted netshares (below /mnt) and caches them. This symlink construction is the reason why this bug showed up, by the way.

REPOSITORY
  R318 Dolphin

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/20191206/f5db94ea/attachment.htm>


More information about the kfm-devel mailing list