cannot cut/copy with dolphin

[Kishore Jonnalagadda]

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.