Finding files with non-alphabetical characters in title

JabRef version 4.3.1 on Windows 10 64-bit (I don't have administrative rights to install developer snapshots, e.g. version 5.0)

I like to use regular expression search when linking local files and use the following:
**/.[title].\.[extension]

As far as I know, that should search in the directory and subdirectories of the main file directory for files that contain the title and the proper extension (.pdf). Contain, right? The file name does not need to start with the title.

However, choosing an article in my bibliography and pressing F7 does nothing (status bar simply tells that it finished and found nothing).

What does F7 (Automatically set file links) do? I've tested with many files and get the same result, even when making sure the file name contains no special characters or anything like that.

Okay, after a bit more playing around, it seems that a regular dash is a character that makes F7 fail. In fact, it seems characters in the title (in the file name) that are not regular letters make F7 fail.

---

Example 1
File: BEEMAN & PINCUS - PHYS REV 1968 - Nuclear Spin-Lattice Relaxation in Magnetic Insulators.pdf

Title in JabRef:
Nuclear Spin-Lattice Relaxation in Magnetic Insulators

F7 does not find the file, unless I change the filename to
BEEMAN & PINCUS - PHYS REV 1968 - Nuclear Spin Lattice Relaxation in Magnetic Insulators.pdf.
(Removing the dash in "Spin-Lattice".)

---

Example 2
File: GUO ea - INORG CHEM COMMUN 2010 - Ferroelectric Metal Organic Framework (MOF).pdf

Title in JabRef:
Ferroelectric Metal Organic Framework (MOF)

F7 does not find the file, unless I change the filename to
GUO ea - INORG CHEM COMMUN 2010 - Ferroelectric Metal Organic Framework MOF.pdf.
(Removing the parentheses around "MOF".)

---

Note: in both cases, I did not need to change the title in JabRef, only in the filename.

[jonasstein]

Could you check, if it was really a -? Perhaps it was one of the UTF-8 symbols similar to -.

I did by removing it and then retyping with the regular dash. No change. F7 only linked when I removed the dash completely. And in my second example, there is no dash in the title, but parentheses.

I installed the 5.0-dev--snapshot on my personal computer (also Win10-64) and repeated the process. Same thing happens. F7 can't find the file unless I remove the dash (or the parentheses in my second example).

Out of curiosity, I tested to instead link using the bibtexkey, i.e., using **/.[bibtexkey]..[extension] as the regular expression. I chose to invoke dashes in my bibtexkeys so the examples above got the key Beeman-PR-1968 and I also renamed the local pdf file to this (Beeman-PR-1968.pdf).

No issue in finding the file this time when invoking "Automatically set file links" (F7) even though it contains a dash.

So... why can't a title search handle dashes and other characters but a bibtexkey search can?

An update to this two years old issue;

I have recently come back to JabRef and this issue still persisted in 5.1. Since I had over a 1000 files that were unlinked, I decided to revert to an old version to try things.

Recap of issue: I use the Regular Expression **/.*[title].*\\.[extension] to link files. In the versions since September 2018, JabRef could not find files that contained non-alphabetical (and non-numerical? not sure...) characters in the title. See examples above. Even a simple dash could not be handled.

I removed 5.1 and found and installed JabRef version 3.6.

Marking all of my over 2000 entries and hitting F7 (Automatically set file links), it worked like a charm! Suddenly, my list of over a 1000 unlinked files was down to less than 200! The remaining unlinked files were easily fixed (e.g., title has a colon but filename has a semicolon since Windows don't allow colons in filenames, or filename was truncated due to a very long title, stuff like that).

I don't know what changed between version 3.6 and (presumably) version 4.x to hinder a regular expression search containing non-alphabetical characters in the title (it didn't have an issue with such characters in the bibtexkey then but I didn't test it now).

Now that my entire library is linked, I'll happily come back to the latest version 5.2.

I'll change the title of this issue to a better description.