Backslashes in group search are erased from bib file after saving

JabRef version 5.0

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

Steps to reproduce the behavior:

1. Create a new dynamic group using a free-form search expression.
2. Use backslashes in the search, for example, by using word boundaries in the search (e.g. title = "\bJabRef\b").
3. Save the group.
4. Close JabRef and open it again, loading the library where the aforementioned group was created. At this point, it can already be noticed that search results are not the same as before JabRef was closed.
5. Edit the group. Notice that the backslashes in the search are gone, that is, it is now title = "bJabRefb".
6. If this database is saved, it will be saved without the missing backslashes.

Expected behavior: after loading the database, the group should contain the same entries as when the database was closed.

Additional information: I made sure to disable save actions when testing this.

When I first create my group it looks like this in the database:

1 SearchGroup:JabRef\;1\;title ="\\\\bJabRef\\\\b"\;0\;1\;1\;\;\;\;;

After I close JabRef and reopen it, the backslashes are already missing from my search in the GUI. If I save this database, my group looks like this in the database:

1 SearchGroup:JabRef\;1\;title ="bJabRefb"\;0\;1\;1\;\;\;\;;

In order for JabRef to load my database and include the single backslash I want, I had to include 8 backslashes in my search, like so:

1 SearchGroup:JabRef\;1\;title ="\\\\\\\\bJabRef\\\\\\\\b"\;0\;1\;1\;\;\;\;;

However, if I save my database once, the 8 backslashes become 4. If I open it and save it again, the 4 backslashes become none. I imagine at some point when the database is being loaded ,\\ is being interpreted as a single escaped backslash and is loaded as so.

[douglasrizzo]

I have tested with my database, which contains quite a few backslashes in group searches, and I can confirm that this is fixed for me. Thank you everyone, great work.

[abepolk]

I’m still looking into this issue. I think I have found the line that adds the extra quote character \. Besides the original one pointed out by Tobias above, also see line 121 below:

https://github.com/JabRef/jabref/blob/6c61664a8f715e4011064ddca5cb0ace0b803131/src/main/java/org/jabref/logic/exporter/MetaDataSerializer.java#L116-L126

This quotes it again once the group tree has been serialized into one string. I could remove this, and to keep the class balanced, I might also want to remove the quote call in line 78 below:

https://github.com/JabRef/jabref/blob/6c61664a8f715e4011064ddca5cb0ace0b803131/src/main/java/org/jabref/logic/exporter/MetaDataSerializer.java#L73-L95

This way, the quoting of both the groups and the other metadata could be done at a more granular level in other classes rather than where the serialized metadata is being aggregated in getSerializedStringMap. I would need to know whether saveOrderConfig.getAsStringList() and saveActions.getAsStringList(OS.NEWLINE)below return lists of Strings with ;. Those classes looked a little complicated, but I doubt they would return something with a ;.

https://github.com/JabRef/jabref/blob/6c61664a8f715e4011064ddca5cb0ace0b803131/src/main/java/org/jabref/logic/exporter/MetaDataSerializer.java#L32-L35

What do the save actions and save order configuration represent? Could they contain ;? If not, I am just going to move on and remove those StringUtil.quote calls before working on the rest of this bug.