PDF indexing should be paused when adding a file via drag and drop

[koppor]

JabRef version

Latest development branch build (please note build date below)

Operating system

Windows

Details on version and operating system

Windows 10

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

1. Configure explicit directory for library (refs "General file directory" is not respected when dropping a file #8179)
2. Drag a PDF file from c:\temp
3. Drop file at an existing entry

Expected behavior:

File is moved and renamed

Current behavior:

At first attempt, an IOException is risen:

java.nio.file.FileSystemException: C:\TEMP\xy.pdf -> C:\TEMP\FMC - FMC_ an Approach Towards Architecture Centric System Development.pdf: Der Prozess kann nicht auf die Datei zugreifen, da sie von einem anderen Prozess verwendet wird

Then, the user can detach the file from the entry and try again. Then, it works.

Solution propsal

Stop PDF indexing during drop handling. Start indexing again after drop (includes file move!!) is finished

[btut]

I think pausing the indexing does not solve this problem. The indexer is triggered by the change in the list of linked files. The file will be added to the indexing queue when the list changes. If the indexer is paused during the drop, the task will still be added to the queue. After unpausing, the indexer would try to index the file at the old location, because that's what was added to the queue.

IMO it would be better to add the file-link only after the file was moved and renamed, is that possible?

[btut]

Note: I am experiencing different behavior when testing this. For me, the indexer starts after moving the file, but before renaming it.
So lets say I have a file "Downloads/abcd.pdf" and I drag it onto an entry, the indexer tries to read "mypdfdirectory/abcd.pdf" when the file was already renamed to "mypdfdirectory/mynamingconventionapplied.pdf".
Don't know if that is operating-system related or just a roll of the dice. There is one important piece of information that can be obtained from this observation: the indexer stores a reference to the path. That path is changed from the move/renaming operation. This means actually pausing the indexer before the drag and restarting afterwards could actually be a solution.

[koppor]

I am on Windows with a strong file locking build-in. 😅

[btut]

This means actually pausing the indexer before the drag and restarting afterwards could actually be a solution.

Does not work :(

Instead of pausing the indexer, we avoid the addition of the new pdf to the indexing task list by blocking new tasks during the drag&drop operation. Once the drop happened, we create a new task to index the entry that the pdf was dropped on.

Does #8334 fix your issue @koppor?