pdf links not working

[mercergeoinfo]

Running both windows-x64_4_3_1 as well as the4.3.1.jar I have the same issues on Windows 10.
Have reinstalled the .exe with no change to problem.

1. Rename PDF's not functioning at all
   • have tried with and without the "Upgrade external PDF/PS links to use the 'file' field
   • the library and the pdfs are in the same directory
2. Behaviour of "Cleanup entries" unpredictable, ranging from destructive to passive
   • sometimes the file links are erased when cleanup run on multiple entries
   • these can be recovered by selecting individual entries and running cleanup again
   • file links are incorrect. File type set to PDF:PDF and subsequent request to change file type fails as GUI buttons unresponsive
   • bibtex entry for file looks like file = {\:1-s2.0-S1364815212001879-main.pdf\:PDF:\:1-s2.0-S1364815212001879-main.pdf\:PDF:},

Running development version doesn't clean up the bad file paths but running Cleanup on individual entries does change the pdf name to the specified pattern and appends that to the path. Manually emptying the file path for each entry seems to be the only way around that particualr problem

JabRef version on

• I have tested the latest development version from http://builds.jabref.org/master/ and the problem persists

Steps to reproduce the behavior:

1. ...
2. ...
3. ...

Log File

Paste an excerpt of your log file here

[tobiasdiez]

Can you please give a more detailed explanation of what goes wrong and how to reproduce the behavior. Thanks

[mercergeoinfo]

More detailed?! 1. Import each bib file to one library 2. Connect pdf file to each entry 3. Genrate keys 4. Run Cleanup with settings for moving and renaming pdf files There's not much more to it. That then inserts a mess of extra ':PDF' strings into the path found under the "file" BibTex entry

…

On Thu, 13 Dec 2018 at 18:12, Tobias Diez ***@***.***> wrote: Can you please give a more detailed explanation of what goes wrong and how to reproduce the behavior. Thanks — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4535 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ9qzutB9sgwIzCcY2BVLNzyamDKtxxxks5u4op4gaJpZM4ZRdL8> .

[tobiasdiez]

Sorry, but with this information I can still not reproduce your problem. Which bibtexkey pattern do you use, what is the file name and location before and after the cleanup operation?

[Siedlerchr]

Do you have the option "Enforce legal characters in bibtex keys" activated and how does your bibtey key pattern look? Did you ran Generate bibtey key before attaching the pdf?

[mercergeoinfo]

The bibtex keys were generated first using [auth][year]. Enforce legal characters was activated. Here is an example of a file path after several attempts, in various configurations and with 3 versions of the programme (stable exe, jar and development): file = {\:PDF\:PDF:/\:PDF/\:PDF\:/\:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf/\:PDF/\;//\:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf//\:PDF/\://\:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf//\:PDF/\:PDF\:PDF:PDF;:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf:PDF}, I understand that the error is not easy to generate, I found no other reference to it in any search I did. But the piling up of ':PDF' strings in the path is similar to an old issue I saw refered to about 4 years ago. No help. I'm sure.

…

On Fri, 14 Dec 2018 at 08:44, Christoph ***@***.***> wrote: Do you have the option "Enforce legal characters in bibtex keys" activated and how does your bibtey key pattern look? Did you ran Generate bibtey key before attaching the pdf? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#4535 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AJ9qzl3oWQCLXrx6LtiDMtHVs9kqHID5ks5u41bGgaJpZM4ZRdL8> .

[mercergeoinfo]

One more point that may or may not be related (probably not) but JabRef processes aren't killed when the programme closes, they stick around and have to be closed manually in Activity Monitor

…

On Fri, 14 Dec 2018 at 09:11, andrew mercer ***@***.***> wrote: The bibtex keys were generated first using [auth][year]. Enforce legal characters was activated. Here is an example of a file path after several attempts, in various configurations and with 3 versions of the programme (stable exe, jar and development): file = {\:PDF\:PDF:/\:PDF/\:PDF\:/\:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf/\:PDF/\;//\:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf//\:PDF/\://\:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf//\:PDF/\:PDF\:PDF:PDF;:Meyer2009_Article_AMulticriteriaApproachForFlood.pdf:PDF}, I understand that the error is not easy to generate, I found no other reference to it in any search I did. But the piling up of ':PDF' strings in the path is similar to an old issue I saw refered to about 4 years ago. No help. I'm sure. On Fri, 14 Dec 2018 at 08:44, Christoph ***@***.***> wrote: > Do you have the option "Enforce legal characters in bibtex keys" > activated and how does your bibtey key pattern look? Did you ran Generate > bibtey key before attaching the pdf? > > — > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub > <#4535 (comment)>, > or mute the thread > <https://github.com/notifications/unsubscribe-auth/AJ9qzl3oWQCLXrx6LtiDMtHVs9kqHID5ks5u41bGgaJpZM4ZRdL8> > . >

[Siedlerchr]

Please only use the latest version to test. The active processes are a known issues of 4.x

[stefanct]

And now of 5.0 as well because it happens likewise with the current 5.0 snapshot.

[Siedlerchr]

@stefanct Could you be more precise? What did you do and what happened and what was the expecte outcome?

[stefanct]

I was referring to the problem where the java process lurks around after JabRef was supposed to quit. If I can reproduce it I'll investigate. What information would help? stdout and stderr output? Any other log? Specific settings or CLI options?

[Siedlerchr]

@stefanct Log information, what you did before closing JabRef etc. If you have an older verrsion open in parallel etc. Please report your changes here #4458

[stefanct]

Since I was not even able to find any documentation on a log file and -verbose really didnt cut it either... and PDF import being completely broken in current HEAD (which kinda worked in 4.x) and all kind of unhandled exceptions(!?)... I am off to Zotero-land. That has its own problems and I really liked some of the stuff in JabRef that actually worked (e.g., fully .bib-based DB, custom filters (which are also broken in 5.x and don't update counts correctly anymore)... but you already almost lost me by wasting screen space with a facebook icon when I first tried 5.x, srly wtf. In retrospect I would have been more productive writing a few scripts to download PDFs and handle .bibs directly than messing with JabRef. :(

[Siedlerchr]

@stefanct Sorry to hear that you are facing problems, but without any information from your side we can't do anything about it. We don't have a crystal ball. And JabRef 5.x is still under heavy development.
And please be aware that we are fully developing JabRef in our free time and some of us are having a full time job.

Custom filters? What are you referring to? Groups? #4441 ?
Please open an issue or search for an existing one and add details on how to reproduce you error.

Log can be accessed under Help -> View event log.

[Siedlerchr]

Closing this issue due to inactivity 💤
Please reopen the issue with additional information if the problem persists.

[ndwallace]

I've just encountered the exact issue described here, although I am running JabRef 4.3.1 on Ubuntu 16.04, from the .jar file.

I found that the issue only occurs when "Convert to BibTeX format" option is selected in the Cleanup Entries tool.

This problem does not occur when "Convert to biblatex format" is used; this option appears to function perfectly fine.

My current workaround involves converting to biblatex format to rename the files, then converting back to bibtex, and manually correcting the file: field (stripping the additional ":" and ":PDF" thrown on either end, in addition to the duplication of the entry within the field.

Leaving this here in the hopes that it helps others who may have encountered this issue. Will re-open the issue later today with further details.

As discussed in #5603 (not yet indexed by Google at time of writing, hence why I missed it), this issue is resolved in Jabref 5.0.