Dangerous data loss bug: Kate does not save file, and gives no message that the file has not been written to disk

When user did File→Save or just ^S, Kate behaves as usual, giving no message, thus making the user think all is ok.

Only later, when the user investigates why his code modifications in his project have no effect, he investigates and looks at the actual files.

Then the user finds that Kate stopped writing the saves onto disk some time ago in the session. User restarts Kate, and finds that apparently Kate stores stuff in some cache, but stops saving them when user commands ^S.

User cannot believe what he sees. Then he decides to copy the modifications from Kate into vi. With vi, the files are actually been written, so that other programs can see the changes. So, with the help of vi, the work which Kate did not write to disk could be saved. Phew, at least.

It might have to do with the strange thing that Kate sometimes opens multiple buffers for one and the same file. I try to avoid having multiple buffers (one can see that on the left bar) for one and the same file and close the excess buffers that Kate opened. So I suspect that this could be a bug with this buffer logic.

System: Kate 25.12.1, FreeBSD 14.3. 128GB ECC RAM, at least 20-30GB free physical RAM. Sessions had about 40-55 files open when the malfunctions crept up (other bug discussed in other post), and Kate was often never closed and restarted for weeks.

The only way to fix this (for a while, at least) seems to always start a new fresh session as soon as this corruption appears.

Looks like you need to file a bug report - that’s not normal, I’ve never hd an issue with Kate being safe.

Well I am not sure whether it is my fault, and actually intended behavior, as you can open a second buffer of a file if you click “Open” and open a file twice, thrice, that was actually already opened… the file then appears multiple times in the left vertical bar with all the files. Then you have distinct buffers with the same file path and name, that you can edit as if they were different files. So I believed that was a feature that I do not understand. And I tried to always avoid this, as I get confused which buffer is the one I write in… I feel particularly bad when I note I edited two or more of them and have to carefully extract the differences and restore my work with vi’s help…

Kate is absolutely wonderful, and after years I still discover new things… I love it… So I’ll file a bug then. Thank you!

1 Like

I believe you are talking about split views? Where you have multiple “views” over the same document that you can use to edit the document. Saving one of the view will save all others automatically. There is always one document though, if not, that is a bug.

I might be misunderstanding you. It will help if you add a screenshot or video to demonstrate your confusion/issues.

1 Like

No, it is not the split windows. I have a very large 4k screen and I use always a grid of about 3x3 split windows. If I have multiple buffers as described, I can choose one, say, the upper one in the list, in to the upper split window. Then I select the lower buffer into the lower split window.

When I then type something, it is not shown in the other window, which uses the same file path but a different buffer. This is why I try to avoid like hell to accidentally open a file two or even more times because of the differing buffers. My typical session has around 30-60 files, so I sometimes overlook that a file already was open…

And my gut feeling is that this is related to the phenomenon why sometimes Kate stops saving… maybe I closed the wrong one(s) of these buffers when I found out that I opened a file multiple times…

I’ll try later to reproduce that and post screenshots of the described things.

1 Like