yep, the fancy backup features we have only work for files that have been saved at least once...

Of course, as soon as you try to save a file for the first time (after a revision bump, eg 4.6.3 -> 4.6.5), KWrite/Kate crashes. Sigh.

Reproducible: Indeed... :-(
Kate Version 3.6.5 (KDE 4.6.5 (4.6.5))

Okay, I know: my bad, I should have saved my work right away. But the normal user tends to save her/his work rather late in the process of creation, when already a good portion of work has been done, especially if working from scratch.
It should be easy to save the "unnamed" (don't they already have a temporary name, like "unnamed", "unnamed (2)", ... "unnamed (n)" etc.) files/streams to a temp folder and keep the "status" of the stream as to be yet "unsaved"... or?!
They could be deleted after proper exiting of Kate and the usual questioning about saving unsaved work.
I would love to do something about it but doesn't know where to start and have no experiences of bugfixing that kind of code... But I guess it's a rather easy-to-fix bug which helps a lot of desperate users - like me - and might not need copious amounts of coding. Does it?! Can somebody clarify/hint me towards associated problems?

I would also like Kate to have this feature.

This might be related to this bug: I have created a feature request for stashing unsaved documents / changes inside a session: Bug 353654

I also would like to see this feature. I already had a data loss for two times because I began a new document and my system hang up before I saved it. The data was not very important, but it was annoying.

Dear user, this wish list item is now closed, as it wasn't touched in the last year and no contributor stepped up to implement it.

The Kate/KTextEditor team is small and we can just try to keep up with fixing bugs.

Therefore wishes that show no activity for a years or more will be closed from now on to keep at least a bit overview about 'current' wishs of the users.
If you want your feature to be implemented, please step up to provide some patch for it.

If you think it is really needed, you can reopen your request, but keep in mind,
if no new good arguments are made and no people get attracted to help out to implement it,
it will expire in a year again.

We have a nice website https://kate-editor.org that provides all the information needed to contribute, please make use of it.

Patches can be handed in via https://phabricator.kde.org/differential/

Greetings
Christoph Cullmann

I believe kate could handle this better.

my brain knows about the bug and work around it, but most users will get bitten by this.

when opening a new file, a temporary backup needs to be created to prevent dataloss

(In reply to Mathieu Jobin from comment #8)
> I believe kate could handle this better.
> 
> my brain knows about the bug and work around it, but most users will get
> bitten by this.
> 
> when opening a new file, a temporary backup needs to be created to prevent
> dataloss

I agree. And I think "avoid dataloss" should be every programmers #1 value / priority.

Hey, why was this reopened a few days ago after so long?...

---

I think it's a very valid feature request, but it's controversial. It's the Mac philosophy where TextEdit stores unsaved docs in the cloud encrypted by default, or if that's prevented, locally. But in Mac (or iOS for that matter), every app is in its isolated container so privacy is not as much of a concern. 

On the other hand, not sure if you noticed, privacy war has exploded. It's a big question nowadays if and who is willing to store sensitive data with big IT firms, or leave it unencrypted on a disk. Sure, not all data is sensitive, but a permanent feature like this would compromise the potentially sensitive unsaved documents.

File system permission could provide somewhat sufficient measures to prevent unauthorised access but may not be enough. The point is that many wouldn't be convinced that their unsaved files will _always_ be stored say in their home dir is good at all.

So, in my opinion, a solution that's elegant and also acceptable by today's measures would be something along these lines:

When content is added for the first time to a new, unsaved doc, Kate offers a dialog, asking if the user wishes to be able to restore the unsaved document. The actions are 'Yes' and 'No' with a checkbox 'Remember my decision'.

When 'Remember my decision' is not set, Kate always asks. 

When 'Yes' is selected, Kate informs that it will be stored unencrypted. (... or the possibilities from here are many. E.g. offers to store with symmetric encryption with a unique key per doc, or, with one key globally for all unsaved documents, or offers to select a PGP key to encrypt with, etc...)

@Marcell, I understand your concerns, but I don't think its on topic with this issue. Kate does not save files on the cloud. And if you have encryption on disk, there are technologies that provides that outside the scope of your favorite text editor.

The bug fix I would like to see happening here. Is when I run:

shell$ kate ~/filedoesnotexist

and my computer crash, kate current automatic backup features will keep my unsaved changes inside a temporary file. because although the file does not exist, kate knows what it should be called.

now if I open a new file with CTRL-n or by not entering a file name on the command line. kate does not know what file that should be, so it simply does not saved.

I think the fix would be automatically assigned a temporary file name when unknown. and automatically restore these temporary backups when kate next open. maybe upon being asked "You have 3 temporary backup files, Would you want to open them now?"

Thank you

I vote for this issue!

Apparently there is already a patch coming for the Stash solution for this

https://invent.kde.org/utilities/kate/-/merge_requests/228

Isn't this fixed now as long as one uses sessions?

(In reply to Kishore Gopalakrishnan from comment #13)
> Isn't this fixed now as long as one uses sessions?

"as long as one uses sessions" isn't this.

Actually, even sessions aren't such a safe haven according to bug 477979
Anyhow I'm unsure if this bug should *duplicate* or *depend* on bug 353654