https://bugs.kde.org/show_bug.cgi?id=402017
--- Comment #64 from Göktuğ Kayaalp <s...@gkayaalp.com> --- I too have encountered this bug a lot, as recent as this morning where I almost lost a PDF I had tracked down. I’m not knowledgeable in Qt or C++, but I’m looking around in the codebase nevertheless, in the hopes that I spot something useful. I see that, in document_p.h, there’s this definition QVector<Page *> m_pagesVector; which probably does hold the data necessary to save even if the original document is gone. Now, as an Emacs user I observe the following patterns: - A file that looks like ‘.#<filename>’ is created, this is a lock file, used to prevent simultaneous editing - Emacs listens on the target file ‘<filename>’ using file system notification libraries. If you edit a buffer that visits a file that has been edited outside of Emacs, it will query you, asking you to either confirm the edit, cancel the edit, or to ‘revert the buffer’ before editing, which means to update the contents of the buffer re-reading the file from disk. - When enabled, Emacs writes backup files after each save, which look like, without customisations, ‘<filename>~’. This is governed by a variety of environment and in-Emacs variables, but the created file contains the version of the edited file as it was before it was saved, e.g.: - open file.txt, containing "hi" - append ", john" - save - file.txt~ is created, containing "hi" - file.txt is overwritten, containing "hi, john" - The contents of a buffer is separate from the contents of the file, the data is spared in memory even if the file is deleted, so you can save a buffer into a file regardless. I doubt it’s desirable to copy this wholesale to Okular, but the following could be done: - Upon opening a file, it’s wholly read into a buffer as a string of bytes, which acts as a buffer between the Document class, and the on disk file. This would ensure that data is always in memory, but without taking up too much space, as indicated in the 53rd comment in the thread: Phil 2020-08-21 11:35:55 UTC writes: > Note: Okular takes 800 MB to render a 5.4 MB file I'm reading; keeping > it all in memory would require *at most* 0.7 % more memory. Why not do > that if memory is available? (https://bugs.kde.org/show_bug.cgi?id=402017#c53) - Okular keeps tabs on the file through filesystem notification libraries like inotify, kqueue, etc., and alerts the user if the file on disk is changed, asking them to take action. - If the user has enabled auto-reloading the files, Okular filters for deletion events and apparently destructive events (i.e. new contents of the file do not constitute a valid document, or file is deleted, or new file is empty, or user does not have read/write permissions anymore), and the user is again queried as to what to do. - When the user attempts to exit the application, Okular checks if the file is somehow destroyed or modified, and offers the user one last chance to record the file as it appears in Okular. - These queries would look like the example modal below, with slight variation depending on the triggering event: ,---- | The file ‘/home/u/some.pdf’ has been modified outside Okular. Before | further modifications, you need to decide how to respond to these | changes. | | [_S_ave as a copy...] [_C_ancel] [Edit anyways...] [Overwrite] `---- - ‘Save as a copy...’ means the document as it currently is in Okular is saved under a new name, and Okular switches to that file for the current document. - ‘Cancel’ cancels the attempted modification by the user. - ‘Edit anyways...’ allows the user to continue editing the document, without creating a copy. The user is responsible to ‘Save’ or ‘Save as...’ the document later. This option is dangerous, so does not present a mnemonic keyboard shortcut. - ‘Overwrite’ will overwrite the file the current document targets with the contents of the document as they currently appear in Okular. This option too does not get a mnemonic keyboard shortcut, as it’s destructive. The above would perfectly remedy the problem at hand, and below are some possible enhancements: - ‘VERSION_CONTROL’ and ‘SIMPLE_BACKUP_SUFFIX’ could be respected, as they appear in "(coreutils) Backup options" info manual (https://www.gnu.org/software/coreutils/manual/html_node/Backup-options.html), accompanied by options in the Okular’s preferences system itself - Even if the above is not set, Okular could preemptively store copies of files in a known temporary location like ~/.cache and/or /tmp; and use lock files and file notifications to prevent alterations to documents it’s displaying. Even if this whole thing is too much, Okular keeping the binary source file data in memory along with the costly object tree that it uses to render the file could help with the case that bites the users most frequently: download file through browser, which saves it in a tmp dir, and if you exit the browser before you save a copy in okular, the browser will remove the tmp dir, leading to this problem. Hope this was useful as a user perspective, comparing it with software that handles this more gracefully. I doubt I could contribute any code in reasonable time without extensive guidance, but I’m totally willing to help with testing any attempts. -- You are receiving this mail because: You are the assignee for the bug.