Version: unspecified (using KDE 4.6.0) OS: Linux I have a symlink to the Dropbox directory (e.g. ~/dropbox -> ~/some/path/Dropbox). While the plugin works wonderfully for the Dropbox directory, it unfortunately doesn't work for the symlink (i.e. no emblems or context menus). Reproducible: Always Steps to Reproduce: 1. Enable plugin 2. ln -s /path/to/Dropbox/directory ~/dropbox 3. Go to ~/dropbox in Dolphin Actual Results: Plugin doesn't work for ~/dropbox Expected Results: Emblems and Dropbox context menu in ~/dropbox
Resetting assignee to default as per bug #305719
same for me, confirmed.
Git commit 1a1ba8184ddc37e6dd82c81cd954a92c6e55455d by Emmanuel Pescosta. Committed on 17/02/2014 at 10:58. Pushed by emmanuelp into branch 'master'. Added a Dropbox version control plugin for Dolphin. This Dropbox plugin is based on the work of: Sergei Stolyarovs - https://bitbucket.org/cancel/dolphin-dropbox-plugin Thomas Richards - http://trichard-kde.blogspot.co.at/2010/12/introducing-dropbox-integration-for.html What I have done: - Ported the old source code to the newer KVersionControlPlugin2 interface - Use the Dropbox client to form the context menu more dynamically (If the Dropbox guys add a new feature to their client, Dolphin can make use of it automatically) - Fixed a crash (Dolphin-4.8.2 segfaults when a file with special characters is present) - Replaced the item version changed timer with a file system watcher -> No useless updates and immediate update on changes - A lot of code/coding style related changes - Made symlinks work with Dropbox Related: bug 298199 FIXED-IN: 4.13.0 REVIEW: 114812 M +1 -0 CMakeLists.txt A +12 -0 dropbox/CMakeLists.txt A +224 -0 dropbox/fileviewdropboxplugin.cpp [License: GPL (v2+)] A +52 -0 dropbox/fileviewdropboxplugin.desktop A +88 -0 dropbox/fileviewdropboxplugin.h [License: GPL (v2+)] http://commits.kde.org/dolphin-plugins/1a1ba8184ddc37e6dd82c81cd954a92c6e55455d
the last claim, > Made symlinks work with Dropbox is an exggeration, as explained in the review request: https://git.reviewboard.kde.org/r/114812/#review48802 this only works for some symlink scenarios (likely most), but the correct one isn’t implemented (i’ve prototyped it here: https://gist.github.com/flying-sheep/8832222) the currently implemented approach will fail in scenarios like the following: dropbox has saved the path /home/username/foobar/Dropbox, and /home/username/foobar is a symlink to /home/username/baz. browsing to /home/username/foobar/Dropbox will lead you to a directory that’s clearly the dropbox directory, but isn’t recognized by the plugin. i.e. every time the shell command “realpath /path/that/dropbox/has/saved” doesn’t yield /path/that/dropbox/has/saved. (which is the case if there are symlinks in the path) ergo, this bug ain’t fully fixed. sorry.
eh, sorry, the second sentence should read: > [the currently implemented algorithm] only works for some symlink scenarios (likely most), but the correct [algorithm] isn’t implemented (i’ve prototyped it here […])