Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Associating PDF with Vanilla Reference #253

Closed
Wonderkitten opened this issue Oct 20, 2020 · 4 comments
Closed

Associating PDF with Vanilla Reference #253

Wonderkitten opened this issue Oct 20, 2020 · 4 comments
Labels
🐛bug Something isn't working 🕵investigate Needs further analysis to find the root cause.
Milestone

Comments

@Wonderkitten
Copy link

Hi,

I'm not having any joy when trying to add a local PDF to a Vanilla Reference in 0.82 on Windows. I get the pop up with a dbl click, get the file browser, choose a file, but then nothing seems to happen with the underlying reference in the library (it remains vanilla, no file associated). Tried multiple files and references, both local libraries and intranet.

@GerHobbelt GerHobbelt added 🐛bug Something isn't working 🕵investigate Needs further analysis to find the root cause. labels Oct 20, 2020
@GerHobbelt
Copy link
Collaborator

IIRC a vanilla ref always stays a vanilla ref: PDFs added to the library are keyed to their content hash and vanilla refs get keyed differently.

The work-around for now might be to add the PDF to the library, where it should then show up as a new entry, and then copy the bibtex/annotations over from the Vanilla record to the PDF record.

I will have to look into this further when there's more time available; hope the work-around is good enough for you now.

GerHobbelt added a commit to GerHobbelt/qiqqa-open-source that referenced this issue Oct 21, 2020
…df_documents_lock and access_lock interplay via the Associate...() call going directly to the PDFDocument (hence access_lock) while one of the background threads was fetching a list of documents to inspect via Library (hence pdf_documents_lock -> access_lock for each doc): the deadlock occurred because the Associate..() call internally would *add* the new PDF into the Library (hence: pdf_ddocuments_lock inside an access_lock zone, hence DEADLOCK with the bg thread!)

Also note that this issue uncovered another matter: PDF association with a Vanilla Reference was not working AT ALL: fixed that as well. (WARNING: association via 'FromWeb' a.k.a. SearchWeb will not deliver AFAICT: only FromLocal associations will deliver.

This uncovered yet another bug, which involved the metadata copying code (which still has some TODO's to be addressed at a later time!) resulting in the associated PDF then being marked as a vanilla reference *itself* due to overzealous metadata copying, which includes the 'FileType' field: 'pdf' or 'vanilla_reference'. Fixed as well.
GerHobbelt added a commit to GerHobbelt/qiqqa-open-source that referenced this issue Oct 21, 2020
…lls (which return a `bool?` type!) are checked the same way, by explicit comparison against `true`, so `null` and `false` are always treated the same way.
GerHobbelt added a commit to GerHobbelt/qiqqa-open-source that referenced this issue Oct 21, 2020
…lls (which return a `bool?` type!) are checked the same way, by explicit comparison against `true`, so `null` and `false` are always treated the same way.
@Wonderkitten
Copy link
Author

Amazing, thank you so much for your prompt response. Workaround is fine for now!

@GerHobbelt
Copy link
Collaborator

GerHobbelt commented Oct 21, 2020 via email

@GerHobbelt
Copy link
Collaborator

GerHobbelt commented Oct 21, 2020 via email

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
🐛bug Something isn't working 🕵investigate Needs further analysis to find the root cause.
Projects
None yet
Development

No branches or pull requests

2 participants