cannot cut/copy with dolphin

[Duncan]

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.

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

___________________________________________________
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.