On Monday 28 Oct 2013 10:31:12 AM Duncan wrote: > Kishore Jonnalagadda posted on Mon, 28 Oct 2013 14:06:53 +0530 as > > excerpted: > > I can't be sure from when this problem occurs but its quite recent. I'm > > on KDE 4.11.2 and i cannot cut or copy files in dolphin with either the > > context menu or the CTRL+C and CTRL+V shortcuts. > > > > I tried installing konqueror and the problem is the same in there. > > The problem does not exist for a new user that i create. > > Copy/Move by drag&drop operations works fine. > > > > When i try to cut a file, the file briefly becomes light shaded (like it > > usually does when a file or folder is cut) but then restores itself to > > the normal icon in about a second. When i click copy on any file i do > > not get the paste option like i would expect it to. I do notice that > > klipper updates the file path each time i try to cut or copy. > > > > Do anybody know what could lead to this? > > That's a very interesting problem. I have little idea what this issue > might be, but the fact that it exists for your normal user but NOT for a > new user indicates it HAS to be something in your normal user's config. > > That means the problem should be resolvable by bisection. =:^) The > general idea of bisection is to repeatedly test whether the problem is > there or not, cutting the test space (the number of config files in this > case) roughly in half each time, depending on the results of the previous > test. > > More specifically, nearly all of a user's kde config is found in the > $KDEHOME directory (normally ~/.kde, tho some distros will default that > to ~/.kde4 or some such), so your first test will be to verify that the > problem disappears if you start with a clean $KDEHOME. > > To do that, while either not running kde (perhaps from the text-mode > commandline) or while logged in as superuser so your user's kde config > isn't being used, rename the ~/.kde directory to something else, say > ~/.kde.backup. > > Then login to kde as that user and confirm that the problem no longer > exists. Assuming it doesn't, you've confirmed that the problem is in a > config file somewhere in your $KDEHOME directory. > > Next, within the $KDEHOME directory, pretty much all the config is in two > subdirs, $KDEHOME/share/config, and $KDEHOME/share/apps. Most of the > actual /config/ is in config (duh!), while apps is other application > data, so we'll guess it's in config and try the same process with it. > > Again without kde running as that user, delete the new test $KDEHOME dir > created by the test, and rename the backup copy back to its original name. > > Then navigate to $KDEHOME/share, and rename the config subdir to > something else, say config.backup. > > Again login as that user and check if the problem exists again or not. > > If it doesn't, you've now confirmed the problem is within the config > subdir; if the problem exists, it's NOT in the config subdir, so try apps. > > Now assuming it's in config, again without kde running as that user, blow > away the config subdir created by the test, and COPY the config dir from > the backup back in place. Then with the backup still in place to be > safe, cd into the the newly copied config dir (NOT the backup!), and > delete the few subdirs and about half the files. > > Repeat the login test. If the problem exists, then you know the problem > is in the half you did NOT delete. If the problem does NOT exist, it's > in the half you deleted. > > Repeat the process again, deleting the files created in the last test and > restoring all the files you now know are good, while testing half of the > half you know is bad. > > Continue repeating until you either isolate the problem to a single file, > or you're comfortable simply deleting the remaining bad configuration and > redoing it. > > Once you reach a single file, you can either stop there if you're > comfortable blowing it away and reconfiguring whatever configuration it > saved, or continue the process in that file by switching from a file > manager to a text editor for further testing, working first with sections > of the file and then with individual lines, until you either nail it down > to a single line and know where the problem is, or you decide you can > blow away the bad config that remains and reconfigure it by hand. > > The first couple times you do this, it's hard. After doing it a few > times, you'll start to get the hang of how kde organizes its > configuration, and for most problems you can shorten the process > considerably by choosing the correct configuration file (or at least the > handful of files with a common name, say the several plasma* files if > it's a plasma problem) the first time. > > Even here, you /could/ try dolphinrc and/or klipperrc right away, and > maybe you'll be right and one of them is the problem. But the trouble > is, this doesn't sound exactly like a klipper problem, and dolphin > doesn't have a whole lot of configuration for the problem to hide in and > nothing in its configuration that looks remotely related, so those files > may or may not contain the problem, while our chances at finding the > problem in $KDEHOME are very high, and our chances at finding the problem > in $KDEHOME/share/config are I'd guess still something like 70%, so > that's a good place to start narrowing down the possibilities.
Thanks Duncan! Indeed i followed a similar process and came down to kdeconnect. kdeconnect allows your computer to pair with itself which is strange! Pairing with itself was the source of the problem. I don't know the technical reason behind it but i think it has to do with kdeconnect's feature of sharing the clipboard. -- Cheers! Kishore ___________________________________________________ This message is from the kde mailing list. Account management: https://mail.kde.org/mailman/listinfo/kde. Archives: http://lists.kde.org/. More info: http://www.kde.org/faq.html.