You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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
The text was updated successfully, but these errors were encountered:
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?
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.
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.
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
Steps to reproduce the behaviour
c:\temp
Expected behavior:
File is moved and renamed
Current behavior:
At first attempt, an IOException is risen:
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
The text was updated successfully, but these errors were encountered: