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

No, sorry, this is no duplicate of bug 226742!

Bug 226742 explicitly talks about an application or even system crash with subsequent data loss.

The data loss I'm experiencing even happens while the walletmanager is still running, i.e. without quitting and restarting it.

It's sufficient to enter text into a wallet entry, klick save, select another wallet entry so the display changes and switch back to the original, edited entry - in some cases, the most recently entered and explicitely "saved" content will be lost.

I'm also not talking about "all data" being lost or the whole wallet being lost - only the most recent edit, as stated above.

I also cannot see any way how creation and renaming of a temporary file (as explained in bug 226742) could fail in my case, as my wallet resides in my home directory which has plenty of free space. The problem also occured on my previous and on my current computer, so it's also not directly related to hardware issues. My current computer including its disk is brand new now, and still I had a data loss again which finally bugged me to report this issue.

Ok, that's more clear for me now. It's about losing some recent edits. I think I also experienced that in the past, but at that time I thought it was me forgetting to click save or something.

What KDE version are you using?

I'm currently using 4.11.1, but the bug is present since quite a while. (At least 4.10 and 4.9, but probably even farther back.)

The problem is, that as you say, in most cases you do not immediately notice the data loss and when you do, you're not sure any more if you really clicked "Save" the last time or if you even actually entered the missing information or if you only had the intention but forgot to really do so...

In the case I just reported I *know* I did enter the data and I know I clicked "Save" and I know the "Save" button disabled itself after the click, and still the data was gone after I revisited the affected wallet entry.

And I also know this happened at least twice or even three times to me since I reported this bug. (I'm more careful at the moment to check if the information I just entered actually has been stored, as I lost some important data before filing this bug and you learn cautiousness best the hard way...)

Changed severity due to data loss. (The bug creation form lists "data loss" as a (the only) justification for severity ("critical").

I think I have a suspicion of what might happen here:

I think the last edit is being lost if the wallet was updated/changed between opening  the editor and pressing save.

Please try the following:

1) Open a wallet and add a new node in a "passwords" folder. Open it in edit mode.
2) Use a browser (in my case Chromium with wallet integration) to log into a site for which no credentials are stored so far. Confirm to save the credentials to the wallet. (It must be the same wallet to which the opened editor in walletmanager belongs.)
3) Enter some text in the wallet manager's editor and press save.

If you can repeat my observations, the save action will seem to be successfull, but if you re-open the edited node's contents, your changes will be lost.

Maybe an open editor's contents are (accidentally or even intentionally) discarded in the background if the wallet is written to, maybe to avoid overwriting changed data with obsolete information? Is the wallet prepared for concurrent edits?

Needless to say, that this issue is a real PITA, given that noticing when your changes are lost, is way after the fact. 

If your theory is right, something should be done about it. It might be, that the editor is open for a longer time, but it should be able to check, if the underlying data structure has changed, and reload it BEFORE starting an edit. Most users will edit some text and press save immediately.

@Valentin: this bug is open for more than 18 month now, people are loosing their most sensitive information due to it in one of the most sensitive areas an DE can have, isn't that enough for taking some care about it? 

This is giving me a hard time to carefully choose my words without letting my feelings through..

(In reply to Hans-Peter Jansen from comment #7)
> Needless to say, that this issue is a real PITA, given that noticing when
> your changes are lost, is way after the fact. 
> 
> If your theory is right, something should be done about it. It might be,
> that the editor is open for a longer time, but it should be able to check,
> if the underlying data structure has changed, and reload it BEFORE starting
> an edit. Most users will edit some text and press save immediately.
> 
> @Valentin: this bug is open for more than 18 month now, people are loosing
> their most sensitive information due to it in one of the most sensitive
> areas an DE can have, isn't that enough for taking some care about it? 
> 
> This is giving me a hard time to carefully choose my words without letting
> my feelings through..

Well, this stopped reproducing on my system but right now I do have some time so I'll look into it right away. And BTW, I'm resumed work on KSecret Service and hopefully this kind of annoyance will go away forever :-)

(In reply to Gunter Ohrner from comment #6)
> I think I have a suspicion of what might happen here:

I'm running a KF5-based session, so I have kwalletmanager5 and kwalletd5. I try to reproduce your scenario:

- open kwalletmanager5 and create a "test" entry, and select it; i don't enter text yet
- use the kwallet-pwgen & kwallet-query to create a new entry named "test-cli"; this is the same as google chrome saving some data; I can see the new entry appearing next to the test entry in kwalletmanager5
- now I return to kwalletmanager5, enter some text then click save
- I navigate away from these entries in kwalletmanager5 and then return to the "test" entry and see it was *indeed* saved.

However, I'll continue my research, as I remember there's a timer inside kwalletd that delays updates. Maybe it's logic has some unknown flaws.

Try closing the wallet after saving the changes. While at it, do you see a chance to execute fsync() on the fd in question immediately after the write()?

How does kwalletd handles fds? Are they kept open while the wallet is open? 
KDE is notorious in loosing settings during an unclean shutdown. Maybe the flaw is way below in the library stack..

Ahh, forgot to mention: I really appreciate your immediate actions, and be assured, others do too, even if they didn't notice this! 

Last thing: if you find the glitch and have a fix, that must be backported to KDE4 (I can try to do this for you, if you like!).

I have further information on that bug:

Apparently, the saved data is not relly lost, but is stored to the wrong folder in the wallet, which causes obsolete data to remain at the desired location and makes the current data hard to find.

eg. I have a folder called "go" where I manually edit some text pages below the "Passwords" subfolder. Now if I
1) open one of these pages,
2) then save some new passwords using Chromium (which uses kdewallet on my system), Amarok or another application which stores its data in the wallet,
3) edit the text page opened in step 2 in KDE WalletManager and
4) press "save",

the changed text is added as a new node below the "Passwords" subfolder of the "Chrome Form Data" or "Amarok" node in the wallet, ie. it is saved to the most recently altered top-level folder.

Apparently the open editor page relies on some internal state and expects something like the "current" top-level folder to be its parent, even if the "current" top-level folder has been changed in the meantime by another application accessing the wallet.

I've just experienced something like this today (kwalletmanager5, Kubuntu, 15.08.2)
Would like to add an interesting datapoint.

I also use wallet for manual storage.  In "Passwords" folder, "Passwords" section I create new entries where I cut and paste stuff (yeah, yeah, clipboard ;-)

Over the last session (~2 days), I created two manual entries (call them "N" and "C")
kdewallet->Passwords->Passwords->"N"
kdewallet->Passwords->Passwords->"C"

Created "N", added data, saved it. created "C", added data, pretty sure I saved it.

Came back later to access "N", when I clicked on it in tree (while still viewing "C") a dialog popped up asking me to save "C" (??) so I did.  

Now I'm viewing "N", but it is blank!  (gasping, consternation etc...)
Click on "C" - it's also blank.  Much more gasping.  Click on some others (not "C" or "N") - not blank.  Whew.  Localised.

So I restart and come here to read about bugs; note comment about "moving" entries.
Look around and find:
kdewallet->Akonadi Google->Passwords->"N"
kdewallet->Akonadi Google->Passwords->"C"

both with, thankfully, valid data.
note that original path (kdewallet->Passwords->Passwords->"N") still exists but is empty.

(In reply to happy from comment #13)
> I've just experienced something like this today (kwalletmanager5, Kubuntu,
> 15.08.2)
> Would like to add an interesting datapoint.
> 
> I also use wallet for manual storage.  In "Passwords" folder, "Passwords"
> section I create new entries where I cut and paste stuff (yeah, yeah,
> clipboard ;-)
> 
> Over the last session (~2 days), I created two manual entries (call them "N"
> and "C")
> kdewallet->Passwords->Passwords->"N"
> kdewallet->Passwords->Passwords->"C"
> 
> Created "N", added data, saved it. created "C", added data, pretty sure I
> saved it.
> 
> Came back later to access "N", when I clicked on it in tree (while still
> viewing "C") a dialog popped up asking me to save "C" (??) so I did.  
> 
> Now I'm viewing "N", but it is blank!  (gasping, consternation etc...)
> Click on "C" - it's also blank.  Much more gasping.  Click on some others
> (not "C" or "N") - not blank.  Whew.  Localised.
> 
> So I restart and come here to read about bugs; note comment about "moving"
> entries.
> Look around and find:
> kdewallet->Akonadi Google->Passwords->"N"
> kdewallet->Akonadi Google->Passwords->"C"
> 
> both with, thankfully, valid data.
> note that original path (kdewallet->Passwords->Passwords->"N") still exists
> but is empty.

Since this original bug was opened, KDE Wallet has been ported to KF5, and the manager is now kwalletmanager5. Please confirm what version are you using.

(In reply to Valentin Rusu from comment #14)
> Since this original bug was opened, KDE Wallet has been ported to KF5, and
> the manager is now kwalletmanager5. Please confirm what version are you
> using.

from "About Wallet Manager" :

Version 15.08.2
Using:
KDE Frameworks 5.15.0
Qt 5.4.2 (built against 5.4.2)
The xcb windowing system

running Kubuntu 15.10
KDE Plasma 5.4.3
Qt 5.4.2
Kernel 4.2.0-18-generic

I attached it to this bug because the behaviour seemed to be similar (if not identical) to what Gunter was describing and I assumed that whatever the bug was it was also ported to KF5.
You also mentioned (#9) that you were running KF5 based wallet now etc.

It is not easily reproducible (when I wrote this and the wallet was in that "state" I could reproduce it at will - today it works fine and I can't...)

I'm not sure if the "Akonadi Google" thing is significant or not.

I am also not sure if originally I had some other process open a wallet (#12) while I was doing a manual edit (I mostly use Firefox - AFAICT it doesn't use kwallet, but do also have akonadi stuff and remote desktop sessions etc which do use kwallet)

I would check out the code and debug it and see if I could find it but unfortunately Kubuntu never quite seems to be in sync with what KDE is up to... if you can point me at some diagnostics for kwalletmanager5 I will happily run them if it occurs again.

Thank you for the bug report.

As this report hasn't seen any changes in 5 years or more, we ask if you can please confirm that the issue still persists.

If this bug is no longer persisting or relevant please change the status to resolved.

Yes, hereby confirm this behavior for Version 20.12.2 (version details below).

To recap: it's not reproducible at will, but following conditions increase the chance to get caught by this issue:
 * many different items under Passwords/Passwords (206 here)
 * some delay between editing and attempting to save (minutes/hours)
 * some other kwallet action in between editing/saving
 * some larger amount of text in items

None of the automatic closing actions are enabled.

In order to avoid loosing anything, I adjusted my procedures: when I edit something in my personal kwallet items and the amount of changes is bigger or the time since saving increases, I copy the changed section to the clipboard, attempt to save (actively), switch items, and recheck. In most events, it's missing the changes. 

After reading the whole issue again and checking my wallet, I found hundreds of indications, that confirms Gunters notes of comment #12. 

I see copies of my notes from Password/Passwords in 
 * Akonadi Google/Passwords
 * Chrome Form Data/Passwords
 * Form Data/Passwords
 * KRDC/Passwords
 * LibKGAPI/Passwords 

just to name a few. Well, to be correct, the second level item is spelled "Passwörter" in my locale.

But some items seem to only contain fragments of the original ones. Hence yes, saving seems to fail to save to the correct location in the item tree, if items in other branches are changed in between.

While at it, having a timestamp of the last change of an item would be really nice as well, which would allow to immediately spot the items, that changed last..

I cannot express my feelings, if anybody really get to the bottom of it and might even fix it. If you do and visit the Middle Rhine Valley one day, contact me, and I'll invite you to a lunch/dinner. Promised.

Operating System: openSUSE Tumbleweed 20210302
KDE Plasma Version: 5.21.1
KDE Frameworks Version: 5.79.0
Qt Version: 5.15.2
Kernel Version: 5.11.2-2-preempt
OS Type: 64-bit
Graphics Platform: X11
Processors: 8 × Intel® Core™ i7-4790K CPU @ 4.00GHz
Memory: 31.3 GiB of RAM
Graphics Processor: GeForce GTX 760/PCIe/SSE2