Main PDF Directory: and Main PS directory: preference settings removed. Needed for heterogeneous repositories.

[ajbelle]

As part of checking "issue Attached File Delete functionality #245" I note the Options>Preferences>[External programs] Legacy file fields --------------- are no longer showning, nor do they appear in File>Database Properties. Settings for my repositories have carried across from my ver2.10 install, BUT WHAT DO I DO IN FUTURE? If I move the Endnote file repository I have in "Main PDF Directory:" and "Main PS directory:" I can edit the directory directly in "Exported preferences.xml” with PFE and reimport, but is all support going to terminate!
I have used these fields for heterogeneous linking to a large Endnote Database (not the intended purpose), so retention of these additional paths is useful functionality to me. All I found on the internet were changes to the bibtex file PS and PDF entries. Is there an alternative method to link a second file repository? The helpfile of my V.30 install is not getting past the second page and https://fossies.org/linux/misc/JabRef-3.0.jar/help/en/ExternalFiles.html is the old information.
This maybe should be a forum post.

[lenhard]

Yes, all support for these things is terminated. You can put multiple file links into the file field of a bibtex entry. You just need to separate the path via a semicolon.

[ajbelle]

Thanks lenhard:-( I am not referring to having multiple files linked in the file field, I was asking after the additional paths to directory locations other than set in options>Preferences>External programs"Main file Directory" that the "Main PDF Directory:" and "Main PS directory:" settings allowed (VERY HANDY EVEN THOUGH NOT THEIR INTENDED PURPOSE).
Can you please contirm your reply means that I have to apply the full file specification from the root for the thousand+ files I have in my separate Endnote directory (outside the "Main file Directory") . Am I missing something?

[matthiasgeiger]

I'm not sure whether I understand your use case correctly... You have used the "legacy fields" pdf / ps to define file links which are based outside your set "main file directory"?

So your entries have both: a file field AND a pdf/ps field pointing relatively to different files (in different folders)?

If so, then you cannot retain this behavior with JabRef 3.0+.

Or do you have only the pdf/ps field but no additional file link? So what you basically want is to define database specific "main directories" which are used for relative linking?

If so, you should use the functionality to define a database specific main directory. Accessible via right-click on the database title tab -> "Database properties".

[simonharrer]

Maybe paste a small excerpt of your bib file here, as this may clarify things.

[koppor]

@ajbelle bump

[ajbelle]

Sorry for delayed reply gentlemen.
@matthiasgeiger Thanks for your hint ---> Accessible via right-click on the database title tab -> "Database properties". It is the closest to my case, however I can only get JabRef to access the files in a single base directory I enter here rather than across multiple base file directories (folders on my Win7 hard drive) simultaneously. If I complete both fields JabRef only accesses the User Specific file directory:!
I insert the .bib file fields (@simonharrer) so you can see that there are only single relative file links against each BibTeX entry. I don't have multiple files for each entry for this test file.

from the .bib file :
Entry calling from base directory E:\JabRef_library
File = {:°paper\°CFD\°LES\leveque2007A- Shear improved Smagorinsky model.pdf:PDF},
--- From totally BibTeX separate entry below -------------
Entry calling from base directory E:\CRC Share\endnote\Data\PDF
File = {://7276-2854935553/7276.pdf:PDF},

As set up for test .bib by RMB on the database title tab -> "Database properties"
from the .bib file:
@comment{jabref-meta: fileDirectory:E:\JabRef_library;}
@comment{jabref-meta: fileDirectory-abelle-LTN-AMC-18QL102:E:\CRC Share\endnote\Data\PDF;}

This does not replicate the behaviour that JabRef provides with the legacy fields (that are still present in my preferences as set through legacy fields by an older JabRef version)
from exported JabRef_Preferences.xml file:

The above preferences make JabRef search both the default and the legacy base directory locations for file links that within the BibTeX file provide no indication of their different directory locations. This is what I meant by a heterogeneous file structure. The current JabRef version seems to expect a single base directory location for all pdf files.

I could provide a directory link/mount (within the Windows file system) to the second ‘base directory’ so that JabRef did not have to search both paths (The second one containing the imported Endnote pdfs.). I don’t know how to, but this is the simple and singular capability that my ‘misuse’ of the legacy directory fields provided.

Once again, sorry if I am missing something.

[koppor]

The pdf field is used by some people to have notes on the paper in a different file and to have two columns in the entry table: one for the notes and one for the PDF. See message by Guido Milanese for details: https://sourceforge.net/p/jabref/mailman/message/34736202/

[ajbelle]

@koppor I can see others would use this, but it is completely the reverse requirement I have identified, which is a single relative file reference within by 'jabref'.bib file entry that is searched for by JabRef in two root directories without having to provide the complete file spec for the second repository root directory. THIS IS A VERY USEFUL CAPABILITY THAT SEEMS LOST in the current JabRef revision, and presumably could be resurrected as a new JabRef 'feature' if in the background as the "Legacy pdf directory" being rebadged the "Alternative repository root directory". I believe it is just an alternative search path added to the file search specification. Because my configuration file already has the "Legacy pdf directory" included it still works for me at the moment, but not if the JabRef ‘back end’ terminates what the ‘front end’ already has.
The ability @koppor mentions no longer is available, because it is ‘front end’ program changes that were implemented in the revision. There are probably other users that are unaware they have the issue I have raised because their files in their files in legacy locations are still found while the ‘back end’ is left alone.

[tobiasdiez]

So if I understand you correctly, you want to specify more then one folder in Database Properties -> General (or user specific) file directory, right?
Moreover, if both the general and the user specific path are specified, then also both paths should be searched (currently only the user specific folder is taken into account).

[ajbelle]

@tobiasdiez Yes you take is absolutely correct. The very singular ability to add a “User Specified Directory” that is searched if the .pdf (or other) file is not found in the "Main file Directory" specified. JabRef did this perfectly for me (by my miss-using the legacy pdf and ps directories setting) |Jabref Ver2.10|Preferences>External programs "Legacy PDF Directory:" and "Legacy PS directory:"), so it should not be a major recoding to reintroduce the "Legacy pdf directory" renamed the "Alternative pdf file directory."
If a user could add more than one "Alternative file directory" to the search file path, it would make JabRef handling of heterogeneous repositories more flexible and a real strength.
At the moment it still works for me because the JabRef_Preferences.xml file still contains:


This means that |Jabref Ver3.0| still lets my install find the files with the alternative root locations.

IF NOTHING ELSE COULD THE ABILITY TO LOAD THE ABOVE VIA |Jabref|Preferences>Import preferences>’JabRef_Preferences’.xml be retained so I can still access this great capability (via the remaining back end support).

[matthiasgeiger]

so it should not be a major recoding to reintroduce the "Legacy pdf directory" renamed the "Alternative pdf file directory."

It's not that easy... "legacy pdf directory" refers to the "legacy pdf field" in the bib file - which stores the information in a field named pdf - those fields have been removed as all files regardless of the type are stored in the field file (not since 3.X but since earlier 2.X versions). We decided to drop support for this legacy field (and therefore also drop support for the directory configuration for those fields).

Personally, I don't like to introduce the additional configuration ability to add another "pdf directory" - the current configuration possibilities should be enough for (almost 😉) every use case...

Why is this enough?
a) this is absolutely no issues if absolute paths are used - so one strategy is to use those (which might not possible if you want to use the on different machines, but:)
b) you can use relative paths starting from the directory of the bibfile - so if you use similar folder structures on different machines your use case is still working (drawback moving the bib file around in the file system does not work)
c) as a last fall back you can use the general, and the database-specific folders (Of course, the bug that only folder is searched must be resolved!)

But I will put this onto the agenda of our next dev call - perhaps the other developers have another opinion.

[ajbelle]

Thank's @matthiasgeiger for listing the alternative options. As I understand option a) would require me to alter thousands of file links I pulled in from an Endnote repository, which for my skill level is daunting. Option b) would break my Endnote access to the files (I think). Option c) doesn't work at the moment, but would suffice for my case if it did. It is interesting that Docear (that embeds JabRef as is bibliographic manager) is looking for ways to provide just such multi directory capability.

I realise it was dropping support for field named pdf in the bib file that has withdrawn the need for "legacy pdf directory" and I make no suggestion to resurrect it. The existing functionality within the 'back end' of JabRef to access the alternative repository is still in place however (It still is working for me as explained) so my comment about "not be a major recoding" was because I thought it was a simple matter of writing the file name "Alternative file directory" from a settings field into the key="pdfDirectory" value="the directory location spec"
I can still do this using |Jabref ver3.0|Preferences>Import preferences>’JabRef_Preferences’.xml

I saw this capability as a great feature provided by simply rebadging the key, with no suggestion of reprogramming legacy support. As usual I must be missing something and hope that this key="pdfDirectory" is not deleted or my system (and I suspect other's) will be broken.
THX for all your time and great work, and wish I had the skill to program it myself :-). I realise you are all heavily loaded and will leave it to your wisdom.

PS: I did manage yesterday to get symbolic links running on my WinDOS box so personally that is my fallback option d), if the above functionality is taken out of the backend :-). I can send you my self-instructions on how I made symbolic links work on Win7, if it isn't seen as "how to suck eggs" to a programmer as it is very easy once you implement it.

[oscargus]

Interesting that it still works. :-) I checked the code and it is not really obvious why (but then I have no idea how it worked earlier either).

"pdfDirectory" is only accessed when upgrading from an older version and when drag-and-dropping a PDF (this is probably not wanted by the way). fieldname + "Directory" is accessed in a few more places and might still add the possibility to introduce specific directories for each filetype. No idea how it works though.

[ajbelle]

Thanks @oscargus for your checking and all others who helped:-)

All I can confirm is that my repository as it stands links to thousands of files from and Endnote repository that I connected originally using the legacy pdf field (or at least that is how I thought I made it work.). The entries in my .bib file appear thus:

Legacy Endnote entry eg: File = {://z2 A summary of exp/z2 A summary of exp.pdf:PDF},
Entry in Main File Directory eg: File = {:°paper\°misc\fisher1942G- Geff and Mutt.pdf:PDF},

Both are located within their respective directories, that originate a different roots on the same partition (neither is a subdirectory of the other and there are no 'links' known to me). There is nothing related that I can find in my system or user variables on Win7.

I now have my fall-back option d) above so won’t waste more of your valuable time on this one. I REMAIN CONCERNED THAT OTHERS MAY HAVE SIMILAR WORKING HETROGENOUS FILE STRUCTURES THAT MAY BREAK IF FUTURE JABREF REVISIONS and hope it is just some setting on my instal that provides me this great functionality (I only install the latest JabRef without uninstalling, so perhaps that is why it still works). I give up:-(

[koppor]

@ajbell Your "Legacy Endnote entry" should be PDF =, shouldn't it? Would it be possible that you send me a mail with your complete entry? I will keep it private. E-Mail is on my GitHub page. Refs #98

You did not symlink every file, did you? 🌻

[ajbelle]

No @koppor , I am on a Billious Gatus WinDoze7 box, and only found out how to do symlinks after my original post. Now I can create them this issue is no longer a problem for me, and I conclude symlinks are the sensible way forward for everyone (as it always probably was if BG-doze wasn't so retrograde).

As stated previously I have never used the legacy PDF = field. In the "Main file directory" location an entry looks as follows:
File = {:°paper\\°CFD\\°BL\\°RANS\\gorle2012A-Epistemic uncertainty.pdf:PDF},

As requested I paste below a compete entry from my .bib (JabRef) file, that accesses the 'legacy' collection. It appears equivalent in all respects. I use the ° to distinguish directories I create that must not be moved/deleted/changed, but these do not appear in the legacy directory structure. It is access to a legacy collection at a different root location I have been asking about (which my install clearly does as the root directory accessed in the examples given are different), NOT THE Legacy PDF= field within a .bib file entry.

@Article{meynart1980Aequa,
  Title                    = {Equal velocity fringes in a rayleigh-benard flow by speckle method},
  Author                   = {Meynart, R.},
  Journal                  = {Applied Optics},
  Pages                    = {1385-1386},
  Volume                   = {19},
  Year                     = {1980},
  Number                   = {9},
  Author_address           = {Roland Meynart Universite· Libre de Bruxelles},
  Call_number              = {950/19-1385},
  DOI                      = {http://dx.doi.org/10.1364/AO.19.001385},
  En_record                = {4079},
  File                     = {://meynart ao 1980-1888862720/meynart ao 1980.pdf:PDF},
  Timestamp                = {ENexport 2012/12/14}
}

Things with EN are my own fields and entries related to the Endnote repository/database and could not provide the directory access I experience.
I hope this clarifies any remaining question, and sorry I haven't been able to make it clearer :-( Judging by your responses, I have set something up somewhere many years ago that provides access to the different root directory locations without realising it, but it is not in my system variables or any directory linking that I can find. I have clearly misunderstood that it was the <entry key="pdfDirectory" value="E:\CRC Share\endnote\cavitationX1.Data\PDF\"/> in the confiuration file allowing the access. Thankyou everyone for all you time and effort

[ajbelle]

For your interest yesterday I moved the old EndNote repository into single location (not the main file directory in JabRef) because it was buried deep in deep chain of directories and contained many links to a separate directory using files specs that absolute referenced to the disk root.
OUTCOME: It worked using the method outline above of importing the new directory settings <entry key="pdfDirectory" value="E:\CRC Share\endnote\cavitationX1.Data\PDF\"/> using |JabRef|Preferences>Import preferences>’JabRef_Preferences’.xml. This is contrary to @oscargus findings because it did not work until I reset the 'redundant' field using the still existent 'back door'. Has anyone else tried to replicate this capability? It seems such a nice bonus ability for no programming effort.