SUMMARY When I modify and save the annotations in a PDF document, usually Okular does not reload the file, which is the correct behaviour. The bug is that sometimes, it does. This happens very rarely, and non-deterministically. Once it has happened, it cannot be made to happen again by undoing and redoing the annotations, suggesting it's due to some timing problem or race condition. STEPS TO REPRODUCE 1. Open a document, then starting making changes to the annotations and saving them, navigating around in between. 2. Wait a long time for it to happen. OBSERVED RESULT Eventually the document reloads. EXPECTED RESULT The document should never reload. SOFTWARE/OS VERSIONS KDE Plasma Version: 5.21.5 KDE Frameworks Version: 5.82.0 Qt Version: 5.15.2 Graphics Platform: X11 ADDITIONAL INFORMATION I've been experiencing this bug in all versions of Okular since about a year ago, and for all I know it may have existed before then. I'm sorry the steps to reproduce above aren't of much use. If you have any better suggestions, like patching Okular to record why it's reloading the file and what's going on, I'd be happy to follow them.
(simpler) STEPS TO REPRODUCE Open a document, scroll down a few pages, make a single highlight annotation, save.
(In reply to pbs3141 from comment #1) > (simpler) STEPS TO REPRODUCE > > Open a document, scroll down a few pages, make a single highlight > annotation, save. Does not reproduce here. Can you give more details on what worked for you? E. g. how you opened the file, where and how you saved it, your configuration (e. g. “Reload document on file change”)...
I have "Reload on Document File Change" enabled. The pdf was just something I downloaded, added an annotation to, then hit Ctrl+S. What I meant in Comment 1 was that you don't need whatever complicated steps I said in the report to trigger the bug, just adding a single annotation is enough. I didn't mean to imply this works every time! As I said, it's a rare bug, and I don't have a reliable reproducer. Sorry for the confusion.
Just took a quick glance at part.cpp: // Stop watching for changes while we write the new file (useful when // overwriting) if (url().isLocalFile()) unsetFileToWatch(); KJobWidgets::setWindow(copyJob, widget()); if (!copyJob->exec()) { KMessageBox::information(...); // Restore watcher if (url().isLocalFile()) setFileToWatch(localFilePath()); return false; } It looks pretty foolproof, but could there be a race condition in here? Maybe some caches don't get written out immediately?
Maybe you couldn't reproduce it because you need a spinning disk and low ram to cause enough latency to trigger the bug, and your computer is too good. There's also another (mostly theoretical) race condition: if the document is updated between saving and re-enabling the file watcher, the modification will be missed. Both race conditions (and therefore probably also the bug) can be fixed by recording the timestamp when the document was saved, and ignoring modifications with the same timestamp. If you foresee no problems with this, I can write up a patch and test it out over the next week, then report back whether the bug has disappeared or not.
As I no longer have to mark supervision work, I am no longer spending many hours per week creating and saving annotations in okular, so I haven't actually triggered this bug once since the last comment. It's probably still there, but I have no need to fix it. Since nobody else seems to care, and it probably only happens in rare conditions on old computers anyway, it can probably be closed.