JabRef
open files not working for specific file names
JabRef version
Other (please describe below)
Operating system
Linux Fedora 37
Details on version and operating system
JabRef 5.10--2023-02-16--98c9cbb Linux 6.1.11-200.fc37.x86_64 amd64 Java 19.0.2 JavaFX 19+11
Checked with the latest development build
- [X] I made a backup of my libraries before testing the latest development version.
- [X] I have tested the latest development version and the problem persists
Steps to reproduce the behaviour
I am not 100% certain of the pattern, but this seems to be the problem: while generally attaching files to entries works, if the file's filename includes for instance a :, the file is not recognised by jabref.
Appendix
No response
I believe the underlying problem is a bit more general, as I'm experiencing a somewhat related issue.
As the : character in file names is not supported on Windows systems (since they use the colon as separator after a drive letter), JabRef is probably disallowing them for POSIX systems under a compatibility policy.
My problem is JabRef simply pretends /home/OTHER directories and files thereunder simply do not exist (meaning I can only work with bib/pdf files under my user's HOME directory). They are artificially inaccessible in JabRef, even though permissions are all OK and all other programs raise no issue working outside my /home/my_home directory with set permissions, and I happen to have a TON of files under /home/BACKUP (not mine or anyone's username in my Linux Manjaro box).
I therefore hypothesize recent versions of JabRef (or JabRef's libraries) is now applying a set of pre-set rules to determine whether a /path/to/file is an allowed one (without actually trying and letting the system deny access in case it isn't). This would be the generalization that encompasses both problems: OP's and mine.
I hope I managed to make myself clear this late in the wee hours.
: is indeed a special character. I am not sure exactly how JabRef handles it, but i know for sure that in Java Regex, it needs to be escaped like this: \:. See here: https://stackoverflow.com/questions/14134558/list-of-all-special-characters-that-need-to-be-escaped-in-a-regex. Maybe it works if you name your file like foo\:bar? Although, in general, I would suggest to shy away from using special characters to keep compatibility.
@cnaak your second problem seems different. You can choose a file directory via options > preferences > linked files > .... Here are the docs.
:is indeed a special character. I am not sure exactly how JabRef handles it, but i know for sure that in Java Regex, it needs to be escaped like this:\:. See here: https://stackoverflow.com/questions/14134558/list-of-all-special-characters-that-need-to-be-escaped-in-a-regex. Maybe it works if you name your file likefoo\:bar? Although, in general, I would suggest to shy away from using special characters to keep compatibility.
implicitly, then your idea is that the user knows about which characters developers/OSs deem unsuitable for file names. So, I would suggest to provide a user friendly response, e.g. JabRef has detected a file name that is not compatible. Please rename, or, ideally, it would then allow automatic renaming.
We have a list of illegal chars that are not allowed in file names: And colon is not allowed on Windows. https://github.com/JabRef/jabref/blob/2db30cb26d1140af307042126fe2a3f0ba121f06/src/main/java/org/jabref/model/util/FileHelper.java#L40-L50
We have a list of illegal chars that are not allowed in file names: And colon is not allowed on Windows.
Could the clean up routine check for file names with illegal characters, and then ask the user what to do?
Bulk File renamers: https://alternativeto.net/software/smart-file-renamer/?platform=linux But those only fix files on your disc, not the links within JabRef.
I was thinking of a routine that would go through the entries and check whether the link within an entry contains illegal characters. If that happens, the user should be notified. So, I am thinking of other users, not just me. I can probably solve the problem with some shell commands, but others might not be aware and encounter this "bug".
I think the root cause here is our FileFieldParser because we use colons to separte the mimetype from the file path and the description. And I guess it struggles with the field path containing colons.
While naming/renaming files with JabRef, illegal chars (e.g if you use author or bibtexkey for generating names) are automatically replaced with underscores.
I struggled today (on Windows 10) with linked files not being found by JabRef after I moved them to a new path. The path had no strange characters, but it was long and had many spaces and dashes, including " - ".
I found a workaround by making a junction to simplify the path. In PowerShell:
New-Item -ItemType Junction -Path "Path" -Target "Target"
