Open a linked file from within JabRef (current developer version 5.7) that has a "full relative path" (Baez2004.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).ġ. C:/Users/Literature_database/Baez2012.pdf 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) (b) a "partial relative path" (again, don't know the proper term), i. 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 (a) a "full relative path" (don't know the proper term), i. When adding linked files to JabRef (at least this happened in the older version) you would sometimes end up with files with 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. I have tested the latest development version and the problem persists I made a backup of my libraries before testing the latest development version. # Checked with the latest development build # Details on version and operating system Don't do that.Īpart from that, thanks for the great software. (jabref:15534): Gdk-WARNING **: 12:19:24.373: XSetErrorHandler() called with a GDK error trap pushed. Probably that is not linked to this issue, but the Terminal output says while starting Jabref:ĮRROR StatusLogger Unrecognized format specifier ĮRROR StatusLogger Unrecognized conversion specifier starting at position 16 in conversion pattern.ĮRROR StatusLogger Unrecognized conversion specifier starting at position 25 in conversion pattern.ĮRROR StatusLogger Unrecognized conversion specifier starting at position 35 in conversion pattern.ĮRROR StatusLogger Unrecognized conversion specifier starting at position 47 in conversion pattern.ĮRROR StatusLogger Unrecognized conversion specifier starting at position 54 in conversion pattern.ĮRROR StatusLogger Unrecognized conversion specifier starting at position 56 in conversion pattern. In my bibliography.bib file, files are linked like `file = ,`. I tested absolute paths, they are still working. Nothing happens and _Open file_ in the right click menu is grey. Since I have installed the update, I cannot open linked files with F4, click on the file symbol or with _right click -> open file_. bib file.T … oday i received the update notification and installed the new jabref version 5.1 on my Ubuntu 20.04 via the. I imagine searching for and where the 'something' was all entry types used in the. The current error message for this issue identified the last line in the file, and I only identified it by luck the last listed entry in Jabref corresponded to the fault in the file! By adding a 'new entry' identifier to the read in parser the error location could also be more closely specified. This is a great strength of JabRef/.bib files and so far so good, but entry corruption is easy. Sometimes I do direct PFE edits on my bib file. bib a file in a way that, if a single entry corrupts, JabRef detects the start of the next entry so that only the affected part is lost (not the whole file)? Exporting corrupt entries to "corrupt bib entries.txt" would allow easier checking and resurrecting the entries as required by non-experts. Robustness is more important than speed for me. Ver2.9.2 managed to read the file that had been corrupted by Ver3.6dev, but could not open if Ver3.6dev saved it/exported it again! The development version could open the file it created, but not any second saved or exported versions! Doesn't make sense to me, but again a pre V3 seems more robust. Original reported USER robustness feature request.
0 Comments
Leave a Reply. |