Renaud (Ron) Olgiati posted on Mon, 26 Sep 2011 07:54:03 -0400 as
excerpted:
> Whenever the CD/DVD reader is empty (no disk), it appears in the Panel
> Device Notifier as having an optical disk, namrd "Bluebirds".
>
> A grep on ~/.kde' confirms:
>
> ron@localhost:~/.kde4 $ grep -r Bluebirds * 2>/dev/null
> share/config/kded_device_automounterrc:LastNameSeen=Bluebirds
>
> But I have no idea where it comes from (this has persisted through
> several updates of KDE, from Mandriva 2010.0 to 2010.1, 2010.2 and now
> Mageia 1)
>
> It is a bit annoying; any idea how to get rid of the offending entry ?
>
> Where does the device notifier store its data ?
>
> Cheers,
>
> Ron.
>
> PS Tha same grep on /etc gives no hit, and no Bluebird in
> /home/.kde4/share/config/kded_device_automounterrc either.
FWIW, something like this would be in the user's homedir, not system-
wide. KDE does have the comparable system-wide /usr/share/config/*
location, but in general, that's only going to have installed-package
defaults (unless the admin manually changes something), and this clearly
doesn't fit the bill.
Given that you seem at least reasonably proficient with grep, etc, here's
a couple hints that should help you with admin tasks such as this in the
future.
* strace -feopen <traced app and parameters> 2>&1 | grep -v ... | grep ...
-f is follow thru forks, -eopen says only report on file-open syscalls (-
efile would report on all file syscalls). Output is to STDERR so to grep
it you have to redirect to STDOUT for piping. As you're likely aware,
grep -v reverses the sense, filtering out what you do NOT want, so it's
good for filtering 'icons\|cursors\|fonts' etc opens, that will only be
noise for the search in question. Then grep something of intereest, say
/home/ , to avoid the system library open noise, etc. Of course, you can
redirect the output of that last grep to a file for further examination
or for attaching to a question for the lists, etc, if desired.
Here, since the device notifier is all automated, it'd be difficult to
strace it directly (tho you can attach to an already running command if
necessary). Instead, I'd recommend the strategy of stracing a kde
settings session as the related settings module is opened (probably
hardware, removable devices, in this instance).
* Config bisection
Most of KDE's settings are found in $KDEHOME, defaulting to ~/.kde as
shipped by KDE upstream, but some distros (including Mageia, it appears)
change that to ~/.kde4 , if the user or admin hasn't set the
environmental variable to point elsewhere. (Personally, I don't
like .files, so have mine pointed at ~/kde, not ~/.kde .) However, the
new freedesktop.org standard location is ~/.config and ~/.local for some
things, and a few kde settings are found there instead. (The
environmental vars that change these are XDG_CONFIG_HOME and XDG_DATA_HOME
respectively. I'm guessing that kde5 will very likely migrate many more
settings over to the new XDG* locations.)
So, the first step of a config bisect should confirm whether the setting
is in $KDEHOME or not. With KDE shut down (from a text console or while
logged into gnome or whatever, instead, FWIW, I find the mc, midnight
commander, curses-based "semi-GUI" file manager very helpful for this
sort of task at the command prompt, YMMV of course), move your kde dir to
~/.kde.test or some such. Then start kde and see if the now mostly
default session has the same behavior, or not. If not, you know the
setting is in $KDEHOME.
Assuming that, nearly all kde settings are in two subdirs,
$KDEHOME/share/config and $KDEHOME/share/apps. Again with kde shut down,
delete the defaults dir it created for the last test, and copy everything
back from the backup EXCEPT one of either the share/apps or share/config
subdirs. Restart kde, and check again.
The apps subdir consists of a whole bunch of individual apps subdirs,
while config consists of individual files. Whichever of the two turns
out to be the culprit, continue the process, taking something close to
half of what remains each time, until you've pinned down an individual
file.
When you've reached the individual file, you have a choice. You can
either blow it away as-is and reconfigure the settings it has from
defaults, or continue the process, now with a text editor instead of a
file manager. Most kde settings files are organized like the familiar
*.ini file, [sections] denoted with brackets, followed by value=data
lines. So if you continue, you'd pin it down to an individual section,
then an individual entry within the section. I almost always continue
down to the individual line, just because I'm the curious sort that wants
to find out what setting was giving me all the trouble, but of course,
one is free to stop at any point and recreate any lost settings in the
GUI, if desired.
That process is called config bisection, since you iteratively bisect the
problem roughly in half at each step.
* Now to the specifics of your problem. Repeating a couple excerpts:
> ron@localhost:~/.kde4 $ grep -r Bluebirds * 2>/dev/null
> share/config/kded_device_automounterrc:LastNameSeen=Bluebirds
> no Bluebird in /home/.kde4/share/config/kded_device_automounterrc
> either.
Note that the path of that first grep, and the path of the file you
listed, are different. At first, I couldn't figure out why the first grep
said it was in that file, but then you said it was NOT.
The first path is implied to be /home/ron/.kde4/....
The second is /home/.kde4/...
No username! No WONDER a grep of the second one didn't turn up anything!
I think you'll find the string in question in
/home/ron/.kde4/share/config/kded_device_automounterrc .
=:^)
--
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.
