Hi,

I'm using KDE 4.3.0 and I have experienced the same issue twice. I have shut down my PC properly both times using the KDE facilities for it. After this, when I log in, I see the default settings, not mine. Thus, I have to configure everything in the dekstop and panel. The only thing that keeps is the theme (elegance). I have to reconfigure the wallpaper, widgets on both the desktop and the panel.

My last KDE 4 fresh settings come from 4.1. Since then I have been using the KDE migration tool, which so far, did the job fine all time. This time it seems a bit weird this is happening.

I hope you find the problem soon, because it is a pain in the neck. Are there any files I could back up and restore in case this happens again?

Thanks a lot for your hard work.

PS: Some more info:
PC: AMD 1.2 Ghz 768 MB DDR
Distro: ArchLinux
KDE: 4.3.0
Qt: 4.5.2

For now I have backed up the following files:

plasma-appletsrc
plasma-appletsrc-bak
plasma-desktop-appletsrc
plasma-desktoprc
plasmarc
plasmarc-bak
plasmoidviewer-appletsrc


everything I could find starting from plasma* in ~/.kde4/share/config . I think those would be enough to restore plasmoids configuration if something bad would happen again.


I also had another idea on this, but did not have a chance to check it because did not lose my config since then - try to zoom out the desktop to see list of activities - probably the lost desktop config would be there - in case if by some reason the new default activity were somehow created. This is just an idea with no ground below it - I just remembered another bug https://bugs.kde.org/show_bug.cgi?id=198696 - the plasma config was also messed when desktop type is changed (from Desktop to Plain Desktop for example), but then I found out that original config were safe - it was available in the list of activities when zoomed desktop out.

Hi,

I haved tested out what you say. Before changing anything after my plasma config has been lost, I have zoomed out several times and there is no trace of my customized widgets/configuration. It seems there is a bug somewhere that crashes all and plasma reset to the default configuration.

Next you have the list of things I do to set up plasma the way I like:

1.- Desktop:
- Change the wallpaper
- Add widget "Simple weather forecast" (left upper corner )
- Add widget "Luna" (below the previous)
- Add widget "Crystal monitor 9" (right lower corner)

2.- Panel (from left to right):
- Leave widget "Application launcher" (modern one)
- Add widget "Quicklaunch"
- Add widget "Show widget dashboaard"
- Leave widget "Pager"
- Leave widget "Task Manager"
- Leave widget "Systray widget"
- Leave widget "Digital clock"
- Add widget "Device notifier"
- Add widget "Lock/Logout"

And that's all. Ohh well, I don't whether or not it will have anything to do, but my screen settings and the next ones:

- Radeon 8500LE (opensource driver)
- Resolution 1920x1080 (FullHD resolution)

I hope we can find out why this is happening, apparently, in a random fashion. If there is anything else I can do to trap the bug, please, do not hesitate to let me know.

Best regards! :-)

Ok, after losing plasma config again I have found at least one way to reproduce this. At this time I have remembered that there were a moment when my home partition was full (so I even could not add new konqueror bookmark), but then I have released some space and continued the work. However, after powering off the machine and logging in again I have received default desktop.

So, the way to reproduce config reset is to fill home partition.

0. Backup all plasma config files
1. Fill home partition
1.1. Copy some big file to home partition
1.2. Fill the rest space with "cat /dev/random > tmp.txt"
2. Perform some action with plasma (unlock widgets, move some widget on desktop).
3. killall plasma-desktop
4. run plasma-desktop -> plasma would start with default config

For me the situation when /home partition can run out of space is rather common - even if I have few gigs free, I can start downloading torrent file with new opensuse iso and the space would quietly become zero taking away my plasma config.

Hi guys,

yesterday I also suffered the same issue again. It's quite the same thing that happened to Anton, my home partition was full for a while: I was decompressing a big file and I didn't realize my hard disk was run out of space. Then I released some space (around 4GB) and rebooted since my system was working very slowly. When I logged in again, the default desktop appeared and my plasma config was fully lost. Fortunately, I backed it up a few days ago and I could restore it easily.

I think there is no need to fill up your home partition and try to change anything from plasma config, it's enough by only filling up your home partition, work for a while normally and reboot (or maybe re-log in). In my particular case, before rebooting, I release about 4GB free space, so I don't understand why the reset happened.

I hope you find a solution to this soon, because it's terribly annoying.

Best regards! :-)

I have been looking around the code to find a place where the problem can be fixed. Did not find exact place for now, but here some good starting points if someone would decide to continue:

class Plasma::Corona - a place where config save process is started from:
http://websvn.kde.org/trunk/KDE/kdelibs/plasma/corona.h?view=markup
http://websvn.kde.org/trunk/KDE/kdelibs/plasma/corona.cpp?view=markup

Corona::saveLayout(const QString &configName) - for desktop containment config name would be "plasma-desktop-appletsrc"

then goes to 
CoronaPrivate::saveLayout(KSharedConfigPtr cg)

So, KSharedConfigPtr seems to be the class which deals with actual configuration saving:

KSharedConfig class is defined here:
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/config/ksharedconfig.h?view=markup
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/config/ksharedconfig.cpp?view=markup

and it is also inherited from KConfig which seem to have actual saving code
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/config/kconfig.h?view=markup
http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/config/kconfig.cpp?view=markup

KConfig::sync() - looks like this is the place for saving

If it really suffers from the described problem (loose target file if there is no enough disk space), fixing this here might fix the same bug in all other kde applications (which most likely might suffer from this problem too).

Here I have suggested an algorithm which in my vision should be safe for such operation:
https://bugs.kde.org/show_bug.cgi?id=200341#c2

The actual write operation is a bit deeper - in

bool KConfigIniBackend::writeConfig(const QByteArray& locale, KEntryMap& entryMap, WriteOptions options, const KComponentData &data):

http://websvn.kde.org/trunk/KDE/kdelibs/kdecore/config/kconfigini.cpp?view=markup

If I understand the code correctly, the target file is opened, then writeEntries() is called - which would most likely would fail if the disk is full destroying its original content - and the corrupted file is closed.

        int fd = KDE_open(QFile::encodeName(filePath()), O_WRONLY | O_TRUNC);
        if (fd < 0) {
            return false;
        }
        FILE *fp = KDE_fdopen(fd, "w");
        if (!fp) {
            close(fd);
            return false;
        }
        QFile f;
        if (!f.open(fp, QIODevice::WriteOnly)) {
            fclose(fp);
            return false;
        }
        writeEntries(locale, f, writeMap);
        f.close();
        fclose(fp);


I have thought about another algorithm here:
1. Write config to new tmp file (with same permissions as the original is one exists) near the original one (the original file is not modified)
2. If the write operation is ok, rename tmp file to the name of the original file, so it would replace it with new config

if disk is full, the tmp file won't be created and the step 2 will not be performed, so the original config will be safe.

any comments/objections from developers?

Tried to make some experiments while having 0 bytes on disk.

plasma-desktop-appletsrc became 0 bytes in length almost immediately.

Tried to reproduce the same for amarok (opened options dialog, changed some settings and clicked "apply" button).
amarokrc were not destroyed - the new values just were not saved (eg - check "show splash screen on startup", press "ok", close dialog, open again - the checkbox would be still unchecked)

when clicked on the "apply" button, 2 new files were created in config dir:
amarokrcj20178.new
amarokrc.lock.O20178

both 0 length. So, I suppose, amarok uses the algorithm I have described above - save config to new file, then if success, rename the file to original name.

ark saves config in the same way - old config is not destroyed on fail.



The interesting thing is that for plasma I also have 2 files in the config dir:
plasma-desktop-appletsrc.lock.TO3513
plasma-desktop-appletsrcpr3565.new

- ".new" temp file for plasma is created just like for amarok and looks like plasma config also tries to be saved in the same safe way. But by some reason it does not save plasma-desktop-appletsrc from being cut to 0.

I have made an attempt to write a fix for that - if someone has kde compiled from source code - please try to try this. I do not feel like I will build kde from source on my notebook (don't have much free space for that), so I can't test this and can't guarantee it will even compile

the only modified file is kdelibs/kdecore/config/kconfigini.cpp

first add 1 include line on the top near other includes:

#include <qtemporaryfile.h>


then find commented code (at the end of KConfigIniBackend::writeConfig(...) method) and replace it with the code below:

// original code:
//        int fd = KDE_open(QFile::encodeName(filePath()), O_WRONLY | O_TRUNC);
//        if (fd < 0) {
//            return false;
//        }
//        FILE *fp = KDE_fdopen(fd, "w");
//        if (!fp) {
//            close(fd);
//            return false;
//        }
//        QFile f;
//        if (!f.open(fp, QIODevice::WriteOnly)) {
//            fclose(fp);
//            return false;
//        }
//        writeEntries(locale, f, writeMap);
//        f.close();
//        fclose(fp);

// fix:
        QString tmpFilePath = filePath() + "XXXXXX";
	QTemporaryFile file( tmpFilePath );
	if (!file.open()) {
            return false;
        }

        file.setPermissions(fileMode);

        file.setTextModeEnabled(true); // to get eol translation
        writeEntries(locale, file, writeMap);
	
	if (!file.size() && (fileMode == (QFile::ReadUser | QFile::WriteUser))) {
            // File is empty and doesn't have special permissions: delete it.
            file.abort();

            if (fi.exists()) {
                // also remove the old file in case it existed. this can happen
                // when we delete all the entries in an existing config file.
                // if we don't do this, then deletions and revertToDefault's
                // will mysteriously fail
                QFile::remove(filePath());
            }
        } else {
            // Normal case: Close the file
            file.finalize();
	    
	    // as soon as write configuration finished successfully, rename temp 
	    // file to replace the original config file
	    
	    // Use ::rename() instead of QFile::rename() to get forced overwrite.
	    if (rename(QFile::encodeName(file.fileName()), QFile::encodeName(filePath())) < 0) {
	          return false;
	    }
        }

*** This bug has been marked as a duplicate of bug 206596 ***