Copying entry to another library does not copy linked file(s)

[bilderbuchi]

JabRef version

5.9 (latest release)

Operating system

Windows

Details on version and operating system

No response

Checked with the latest development build

• I made a backup of my libraries before testing the latest development version.
• I have tested the latest development version and the problem persists

Steps to reproduce the behaviour

I am trying to set up a library shared with colleagues (postgresql database), in addition to a local one (biblatex) with my own entries.

As far as I could find out, the only way to share linked files, too, is to set up a collectively accessible location (e.g. a network share). Initially, I expected that linked files would be added to the database -- please tell me if this is possible/I am wrong!

Both libraries work correctly, e.g. I can add and edit entries on the shared one, and add linked files manually.
The local one has a general file directory entry .\my_pdf_storage (relative to the bib file).
The shared library has a general file directory entry \\someserver\network\accessible\folder, and added files appear there.

Now, I want to copy some (many, in fact) entries---including attached files!---from my personal library to the shared one.

1. Drag and drop entry from local library tab to shared one. (or copy/paste, does not make a difference)
2. Entry is created as expected (except for group if not existing, I think this is another issue)
3. However, the General-File field reflects the structure of the source lib, and so the file is lost/inaccessible!

Expected behaviour

I would have expected that upon drag-drop to another library, that

1. Any linked files are looked up based on source library directory settings + file path
2. Linked files are copied to the new library and
3. stored according to destination library directory settings + file path (Files are copied, not moved, otherwise they would be gone from the source library)

(I was not sure if this should be working but is broken (bug) or something that would be an enhancement, so sorry if this is misfiled)

[koppor]

Thoughts:

• Do all users want this behavior?
• Do I want to have a copy of all files (e.g., ex2020.pdf and ex2020 - comments koppor.pdf)

Idea:

• Preference (default: enabled) - that files should be copied
• Copy all files as default
• If modifier key (Alt on Windows) is pressed, at drop a menu is opened with three options: copy all files, copy first file, copy no file
• The file name is generated the same way as if one uses "Download fulltext" functionality. This also works for multiple files.
• NOT chosen: Since the file name pattern is configured globally, there is no action needed for renaming the file
• NOT chosen: When copying the files, the folder hierarchy should be kept

[bilderbuchi]

Thank you for your thoughts!

Do all users want this behavior?

In the situation involving a personal/local and a shared database library, I don't see why you would not want to copy the files of an entry. I mean that, for a shared library, the files need to be in a shared/common location -- why would the files for the local library be in that same location?
However, I'm sure that for the set of JabRef users, you will probably find a user/situation where file copying would not be desirable. 😅

One could ask the user on drop/paste for the desired behaviour.
Let's say we drag/drop (or copy/paste) one or more entries from library A to library B:

1. For every entry:
2. If the entry has one or more files, for every file:
3. Check if the file can be accessed from library A (according to its user/general/... directory settings) with the defined file path.
   • If not, this indicates a pre-existing problem, abort and report.
4. Check if the file can be accessed from library B (according to its user/general/... directory settings) with the defined file path.
   • If yes, both libraries store to the same location, and we're done.
   • If not, the file entry would be broken after copying, so we have to do something:
   • Ask the user if they want to copy the file copied (default?), move the file (if desired?), or the path in the entry deleted.
     • If copy, copy the file to the destination in B according to the "Download fulltext" functionality.
     • If we allow moving, delete it in the source entry to not break that entry. (if you want that?)
     • If delete, delete the file path from the entry that is pasted.
     • Maybe have a "use this action for all files in this entry/all remaining entries" checkbox if there is more than one file.

It seems like with this approach, you can't produce entries with invalid file paths when copy/pasting, which seems desirable to me.
Does that sound useable/feasible to you? Could of course be tweaked by preference settings.

[koppor]

• Report means org.jabref.logic.util.NotificationService#notify (accessible through the DialogService
• No ask of the user - just preference is used
• Accessibility check (outlined above) needs to take care that the relative path might be different - a more "sophisticated" algorithm is needed. Also test cases.
• Preference: "Also copy/move files when copying/moving entries"

---

Place where to add the prefernce:

---

Code hint: Pasing is handled at org.jabref.gui.LibraryTab#pasteEntry.

[u7511506]

Hello, I am very interested in this issue. Can it be assigned to me?

[github-actions]

Welcome to the vibrant world of open-source development with JabRef!

Newcomers, we're excited to have you on board. Start by exploring our Contributing guidelines, and don't forget to check out our workspace setup guidelines to get started smoothly.

In case you encounter failing tests during development, please check our developer FAQs!

Having any questions or issues? Feel free to ask here on GitHub. Need help setting up your local workspace? Join the conversation on JabRef's Gitter chat. And don't hesitate to open a (draft) pull request early on to show the direction it is heading towards. This way, you will receive valuable feedback.

Happy coding! 🚀