Okular stores documents' annotations in ~/.kde/share/apps/okular/docdata and bookmarks in ~/.kde/share/apps/okular/bookmarks.xml. However, when I rename a document, its associated bookmarks and annotations are lost because docdata and bookmarks.xml still contains the document's old filename, path, etc. Reproducible: Always Expected Results: Okular should prompt for the documents new location and modify docdata and bookmarks.xml accordingly. See this post: https://www.linuxquestions.org/questions/showthread.php?p=4943089
That won't happen, we can't match back paths so we can't see something was renamed. You can create an okular archive if you don't want to lose stuff or you can rename the files manually. I understand this is suboptimal so i'll leave the wish open but don't expect any easy/soon fix. Thanks for caring about Okular :-)
(In reply to comment #1) > That won't happen, we can't match back paths so we can't see something was > renamed. You can create an okular archive if you don't want to lose stuff or > you can rename the files manually. I understand this is suboptimal so i'll > leave the wish open but don't expect any easy/soon fix. > > Thanks for caring about Okular :-) Well, I wasn't expecting it to detect if the file is renamed; it'd just prompt for a new path of files it can't find, which shouldn't be too hard to implement. thanks
As said, we can't do that, we do not store paths of files.
(In reply to comment #3) > As said, we can't do that, we do not store paths of files. What writes to ~/.kde/share/apps/okular/bookmarks.xml , then? It contains paths, e.g.: <folder href="file:///tmp/test.pdf"> <title>/tmp/test.pdf</title> <bookmark href="file:///tmp/test.pdf#18"> <title>#19</title> <info> <metadata owner="http://freedesktop.org"> <bookmark:icon name="application-pdf"/> </metadata> </info> </bookmark> </folder>
Ah right, that's bookmarks, was thinking of annotations. We could do for bookmarks maybe. Can you propose what kind of user interface would you like to happen when a document that belongs to a bookmark is not there?
The files in ~/.kde/share/apps/okular/docdata/ that store annotation information also store the document's path in a <documentInfo url="/path/to/file.pdf"> tag. Instead of the "Could not open '/a/certain/file.pdf'. File does not exist" dialog box appearing when trying to open renamed documents, a dialog box like the "Open Document" one would prompt for the new path of file.pdf.
(In reply to comment #6) > Instead of the "Could not open '/a/certain/file.pdf'. File does not exist" > dialog box appearing when trying to open renamed documents, a dialog box > like the "Open Document" one would prompt for the new path of file.pdf. And the corresponding annotations XML file in ~/.kde/share/apps/okular/docdata/ and tag in ~/.kde/share/apps/okular/bookmarks.xml would be updated with the new path.
About the docdata files, do you expect us to open all the files in that folder every time you open a file? That'll be slow.
(In reply to comment #8) > About the docdata files, do you expect us to open all the files in that > folder every time you open a file? That'll be slow. No, I expect that when I click on a bookmark or annotation, in the Navigation Panel, associated to a file which can no longer be found because it's been renamed; Okular should then prompt for the new file's location and update the corresponding docdata file and entry in bookmarks.xml. I don't expect Okular to check whether all the previously opened documents might have gone missing.
Sure, that can be done for bookmarks.xml when you click on a bookmark, but for docdata, how do we do it? To realize a given docdata file is gone i'd need to read them all, no?
(In reply to comment #10) > Sure, that can be done for bookmarks.xml when you click on a bookmark, but > for docdata, how do we do it? To realize a given docdata file is gone i'd > need to read them all, no? Hmm… I suppose; but that search would only have to be done once, when Okular realizes the document has gone missing.
The thing is how do we realize it has gone missing? (Not speaking about the bookmark case that is very obvious, just speaking about the annotated file case here that you renamed)
(In reply to comment #12) > The thing is how do we realize it has gone missing? (Not speaking about the > bookmark case that is very obvious, just speaking about the annotated file > case here that you renamed) By "it" do you mean the annotations XML file? That XML file would already be there, but with the document's old path. If by "it" you mean the document itself, well, Okular already knows if a file is missing or not…
By "it" i mean, i have docdata/123861.np658.pdf.xml that represents a file that was named np658.pdf and was 123861 bytes in size. When should i decide to read this file, go inside it and read <documentInfo url="/tmp/np658.pdf"> and then check if /tmp/np658.pdf stil exists? Every time you start okular?
(In reply to comment #14) > By "it" i mean, i have > docdata/123861.np658.pdf.xml > that represents a file that was named np658.pdf and was 123861 bytes in > size. When should i decide to read this file, go inside it and read > <documentInfo url="/tmp/np658.pdf"> > and then check if /tmp/np658.pdf stil exists? > > Every time you start okular? Suppose you try opening /tmp/np658.pdf in Okular, but /tmp/np658.pdf DOESN'T exist. Then Okular will say the file cannot be found. At that point Okular should prompt for the new, existing path and/or filename—say, /new/path/of/doc/newname.pdf. Then Okular would rename docdata/123861.np658.pdf.xml to docdata/123861.newname.pdf.xml if the filename changed and update docdata/123861.newname.pdf.xml and documentInfo with the new path, /new/path/of/doc/newname.pdf. Okular needn't do any automatic checking of whether /tmp/np658.pdf exists. Now, suppose /tmp/np658.pdf DOES exist, and that its previous path and/or filename was different—say, /old/path/of/doc/oldname.pdf. Okular needn't search for docdata/123861.oldname.pdf.xml and the entry in bookmarks.xml and update them to /tmp/np658.pdf, unless you want to implement this, too; but I don't think that'd be necessary.
Sure, but why would Okular try to open /tmp/np658.pdf ?
(In reply to comment #16) > Sure, but why would Okular try to open /tmp/np658.pdf ? Okular wouldn't by itself, but the user might make Okular do so by clicking on a bookmark associated with the document's old path/filename.
Sure, what about a file with annotations and no bookmarks?
(In reply to comment #17) > (In reply to comment #16) > > Sure, but why would Okular try to open /tmp/np658.pdf ? > Okular wouldn't by itself, but the user might make Okular do so by clicking > on a bookmark associated with the document's old path/filename. Yep, it's definitely possible to fix dangling bookmarks like this: User clicks on a bookmark → Okular says "not found, do you want to locate it?" → Open file dialog It's a little harder to migrate annotations, because docdata files are indexed by filename *and* filesize, while bookmarks.xml only contains the filename. In other words if you have a dangling bookmark to a receipt.pdf file, and you have ten different docdata/*.receipt.pdf.xml files, you can't match the right one. On the other hand, after the user has selected the new path, you can read its size and match them (provided the user has selected the right file). (In reply to comment #18) > Sure, what about a file with annotations and no bookmarks? I think this second case could be handled in a hypothetical "metadata management" panel in the settings, that also lets you list and selectively clean metadata (just dreaming... :D) Note that I'm *not* saying that I/we are going to do it (especially the second part, which is *a lot* of work). This is just my idea. If you agree to what I said, it might be useful to open different bugs to track each of the two cases separately.
Yep, doing the move for a bookmarked file should be easy, for a "only annotated one" you need a special thing in the settings dialog. Fabio if you feel like specifying the two bugs in separate (actually i think there's something around for the "metadata management one") it'd be cool so we can close this one (that asks for two separate things) and have two which asks just for one.
Back to unconfirmed
Saving annotations to PDF directly will be available in KDE Applications 17.12. Let's change this bug to concern the bookmarks storage problem. As Fabio said: > Yep, it's definitely possible to fix dangling bookmarks like this: > User clicks on a bookmark → Okular says "not found, do you want to locate it?" > → Open file dialog …which should not be too complicated. Regarding saving bookmarks to PDF, see Bug 336381. Regarding saving bookmarks to Okular document archives, see Bug 330961.
*** Bug 435582 has been marked as a duplicate of this bug. ***
*** Bug 486567 has been marked as a duplicate of this bug. ***
*** Bug 380330 has been marked as a duplicate of this bug. ***