JabRef version
JabRef 5.7--2022-07-18--be4a7c5
Operating system
Windows
Details on version and operating system
Windows 10 21H2
Checked with the latest development build
Steps to reproduce the behaviour
While using the wonderful "Copy linked files to folder..." function of JabRef 5 I noticed a behaviour of linked files that differs a lot from previous versions (namely JabRef 3.8.2) and which can have serious consequences. When adding linked files to JabRef (at least this happened in the older version) you would sometimes end up with files with
(a) a "full relative path" (don't know the proper term), i. e. you had specified your main file directory in the preferences, and the file would be shown in the "File" field of the editor with just its name, e.g., Baez2004.pdf
and
(b) a "partial relative path" (again, don't know the proper term), i. e. you had specified the same main file directory as in (a), but the file would be shown in the "File" field of the editor with its file name + the directory the file was stored in, e.g., Literature_database/Baez2008.pdf ("Literature_database" is the directory, "Baez2008.pdf" is the actual file)
and
(c) the absolute path, e.g. C:/Users/Literature_database/Baez2012.pdf
Let's forget about (c) since I have not seen the issue so far appear with (c) (in fact I don't even know, whether the newer JabRef versions support absolute file paths).
Now the problem is as follows:
- Open a linked file from within JabRef (current developer version 5.7) that has a "full relative path" (Baez2004.pdf). We assume you have set the correct main file directory in your preferences (e.g., C:\Users\Literature_database)
- The linked file is opened (all is good!)
- Now try to open a linked file from within JabRef that has a "partial relative path" (Literature_database/Baez2008.pdf)
- The file will not open and instead the file manger of the operating system (e.g., Windows Explorer) is opened
- You can get around the issue of (4) if you change your main file directory to the directory that contains the file directory, e.g. C:\Users
- Now files from (4) will open, but files from (2) will no longer open (instead you get again the file manager)
This new behaviour is completely different from JabRef 3.8.2, where - if the correct main file directory was set - it would not matter, whether the file had the "full relative path" or the "partial relative path". The files would always be opened. Below I attach some screenshots of the file editor view of files with "full" and "partial" relative paths for both JabRef 5.7 (current developer version) and JabRef 3.8.2 (both use the same (!) main file directory). Note, that only JabRef 3.8.2 would open always open the files, as long as the correct main file directory was set.
This behaviour also has implications for downstream functions in JabRef, e.g., the "Copy linked files to folder..." will not copy files that it does not find (as in (4)) and it will not even tell you, that it did not copy these files.
Also note: Manually changing the paths is not feasible (?) if you are dealing with a database that contains thousands of entries.
Appendix
JabRef 5.7: Full relative path - file will be opened in (2)

JabRef 5.7: Partial relative path - file will NOT be opened in (4)

JabRef 3.8.2: Full relative path - file will be opened in (2)

JabRef 3.8.2: Partial relative path - file will be opened in (4)

JabRef version
JabRef 5.7--2022-07-18--be4a7c5
Operating system
Windows
Details on version and operating system
Windows 10 21H2
Checked with the latest development build
Steps to reproduce the behaviour
While using the wonderful "Copy linked files to folder..." function of JabRef 5 I noticed a behaviour of linked files that differs a lot from previous versions (namely JabRef 3.8.2) and which can have serious consequences. When adding linked files to JabRef (at least this happened in the older version) you would sometimes end up with files with
(a) a "full relative path" (don't know the proper term), i. e. you had specified your main file directory in the preferences, and the file would be shown in the "File" field of the editor with just its name, e.g., Baez2004.pdf
and
(b) a "partial relative path" (again, don't know the proper term), i. e. you had specified the same main file directory as in (a), but the file would be shown in the "File" field of the editor with its file name + the directory the file was stored in, e.g., Literature_database/Baez2008.pdf ("Literature_database" is the directory, "Baez2008.pdf" is the actual file)
and
(c) the absolute path, e.g. C:/Users/Literature_database/Baez2012.pdf
Let's forget about (c) since I have not seen the issue so far appear with (c) (in fact I don't even know, whether the newer JabRef versions support absolute file paths).
Now the problem is as follows:
This new behaviour is completely different from JabRef 3.8.2, where - if the correct main file directory was set - it would not matter, whether the file had the "full relative path" or the "partial relative path". The files would always be opened. Below I attach some screenshots of the file editor view of files with "full" and "partial" relative paths for both JabRef 5.7 (current developer version) and JabRef 3.8.2 (both use the same (!) main file directory). Note, that only JabRef 3.8.2 would open always open the files, as long as the correct main file directory was set.
This behaviour also has implications for downstream functions in JabRef, e.g., the "Copy linked files to folder..." will not copy files that it does not find (as in (4)) and it will not even tell you, that it did not copy these files.
Also note: Manually changing the paths is not feasible (?) if you are dealing with a database that contains thousands of entries.
Appendix
JabRef 5.7: Full relative path - file will be opened in (2)
JabRef 5.7: Partial relative path - file will NOT be opened in (4)
JabRef 3.8.2: Full relative path - file will be opened in (2)
JabRef 3.8.2: Partial relative path - file will be opened in (4)