GNOME Bugzilla – Bug 770012
Re-saving a file without any additional changes causes all annotations made and forms filled to be lost
Last modified: 2017-10-05 17:59:19 UTC
When saving to an existing file with 'Save a Copy' menu option, the prompt to replace/overwrite the existing file is shown, however proceeding by confirming 'Replace' on the prompt simply closes the prompt and DOES NOT ACTUALLY replace/overwrite the file. Furthermore, when the user then goes to close Evince, no prompt about unsaved changes not being saved is shown, thus data is lost. Steps to reproduce: 1. Grab a fillable PDF form, let's call it 'form.pdf' 2. Copy 'form.pdf' to 'form2.pdf' to make a duplicate 3. Open 'form.pdf' in Evince 4. Make some changes to the form (fill some stuff out) 5. Select 'Save a Copy' from the menu, and select 'form2.pdf' as the save target. 6. Observe that prompt to replace/overwrite 'form2.pdf' is shown. 7. Proceed by clicking 'Replace' in the prompt dialog 8. Observe that dialog closes without errors and no errors are logged to standard output 9. Close evince with the close button 10. Observe that no warning about having unsaved changes is shown 11. Observe that the changes WERE NOT saved in 'form2.pdf'. This can be confirmed by a) observing that modification timestamp did not change, and b) running sha256sum against both 'form.pdf' and 'form2.pdf' results in the same checksum Expected behavior: Target file is overwritten with the new data, or an error is shown stating that it could not be saved. Furthermore, Evince should continue to warn about unsaved data when closed. Actual behavior: Target file remains unchanged, no indication of an error whatsoever, closing Evince results in no warning, meaning data loss. I lost about an hours worth a work due to this bug -- turned out that my frequent saves with 'Save a Copy' weren't doing anything. Some hopefully useful information: Distribution: Arch Linux evince 3.20.1 gnome-shell 3.20.3 libarchive 3.2.1 poppler 0.46.0 GTK 3.20.8 GLib 2.48.1 systemd 231 Linux 4.6.3
This may be an issue with the particular PDF or some local setting (selinux or such). May you please attach it? May you try annotating a different PDF and save it?
I can confirm that it only happens with certain fillable PDFs. Unfortunately, the ones that I have where it happens contain sensitive information. And it seems saving from an empty form behaves as expected. I will try and find a publicly-publishable example.
Ok. I suspect that they may have some Javascript (something unsupported by Poppler, the library used by Evince to render PDF files). I may be wrong though.
If you are fine with it, you could also privately send it to any of us.
I think that the problem is with encrypted PDFs. There is an old bug about that. But to be sure we need a test file.
the test file in the original bug works as expected.
Any new information on this?
OK. I just had some time to fiddle around with this. And I think I got it to be reproducible. It seems that if one does a "repeat save" (as in a save of annotations to another file, but without any new annotations), the annotations just fail to save, and only the original (blank) PDF is saved. Sample steps: 1. Grab the PDF from https://graduateland.com/api/v2/users/jesper/cv (just the first web search result for "test pdf" that any sort of complexity). It really seems to be with ANY sort of PDF, even just a single-line-of-text PDF export from LibreOffice. Let's call this PDF 'test.pdf' 2. Open 'test.pdf' in evince. 3. Using evince, add an annotation. 4. Do a 'Save a Copy' to 'test2.pdf', and leave evince open 5. Observe (using evince or another PDF viewer) that 'test2.pdf' now contains the annotated PDF. 6. In the still-open evince (without adding any more annotations), do another 'Save a Copy' to 'test2.pdf' (and accept the prompt to replace existing file), and leave evince open. 7. Observe (using evince or another PDF viewer) that 'test2.pdf' now ONLY CONTAINS THE ORIGINAL PDF with NO annotations. 8. In the still-open evince (without adding anymore annotations), do a 'Save a Copy' to a different file, 'test3.pdf'. 8. Observe that even 'test3.pdf' ONLY CONTAINS THE ORIGINAL PDF with NO annotations. This is now in evince, GNOME, and GTK 3.22.1. Hope this helps.
Please disregard the original description of this issue, as after further testing, the root cause appears to be the "repeat save" problem detailed in my previous comment. Specifically, i) ALL annotations and filled forms are lost (not just the ones since the last successful save) ii) ALL kinds of PDFs are affected (simple, complex, forms, etc.) iii) ONLY occurs AFTER a successful "Save a Copy" save. iv) ONLY occurs when NO FURTHER CHANGES (in annotations and forms filled) were made, but another "Save a Copy" (following a previous successful one) was performed v) (corollary to iv.) DOES NOT occur if further changes (e.g. another annotation added) are made to the PDF after a successful save. In this case, the following save is successful.
See also bug #744886.
Today I was hit by this bug again and lost all the highlights in a document that I read. IMO this is an important bug due to the fact that it causes data loss.
(In reply to icasdri from comment #9) > Please disregard the original description of this issue, as after further > testing, the root cause appears to be the "repeat save" problem detailed in > my previous comment. Specifically, > > i) ALL annotations and filled forms are lost (not just the ones since the > last successful save) > ii) ALL kinds of PDFs are affected (simple, complex, forms, etc.) > iii) ONLY occurs AFTER a successful "Save a Copy" save. > iv) ONLY occurs when NO FURTHER CHANGES (in annotations and forms filled) > were made, but another "Save a Copy" (following a previous successful one) > was performed > v) (corollary to iv.) DOES NOT occur if further changes (e.g. another > annotation added) are made to the PDF after a successful save. In this case, > the following save is successful. Oh, I am sorry I faled to see these steps. There are indeed very useful and I can reproduce the bug in Evince 3.24, so something odd is happening. I'll take a look
So this bug has been tehre since 2010... @Carlos, now that we have "Save as", we should always save the current version of the document, shouldn't we?
so the problem is that after we save a document that has been modified we clear the "been modified" flags, and hence, use poppler_document_save_a_copy which saves the original file, not the file with the modifications. I'd say that we always should use the poppler_document_save, unless, we have a way of setting the document as non modified inside the poppler api, but I couldn't figure out a way to do that.
Created attachment 360826 [details] [review] pdf: Always use poppler_document_save to avoid data loss We used to use two methods to save a document: poppler_document_save and poppler_document_save_a_copy. The latter only saves a copy of the original document, discarding any change done (e.g. forms and annotations). However, after a document has been modified and saved, if there is no new change and the user saves the document, it will discard even the previous saved changes to preserve a copy of the original document. By only using poppler_document_save to save the content of the current document opened in Evince, to avoid data loss made between saves.
This problem has been fixed in the unstable development version. The fix will be available in the next major software release. You may need to upgrade your Linux distribution to obtain that newer version.