Use relative paths for `file = {...}` field of `.bib` export.

[goretkin]

Sorry if this is the wrong place, since I report ID is not applicable.

The difference is in the file = field.

This is related, but not exactly equivalent, to Zotero's user_pref("extensions.zotero.baseAttachmentPath", "$base_path") setting.

Exporter used: Better BibLaTeX auto exporter ("keep updated")

Desired behavior:

@inproceedings{bohlin2000path,
  title = {Path Planning Using Lazy {{PRM}}},
  booktitle = {Proceedings 2000 {{ICRA}}. {{Millennium}} Conference. {{IEEE}} International Conference on Robotics and Automation. {{Symposia}} Proceedings (Cat. {{No}}.{{00CH37065}})},
  author = {Bohlin, R. and Kavraki, L. E.},
  date = {2000-04},
  volume = {1},
  pages = {521-528 vol.1},
  issn = {1050-4729},
  doi = {10.1109/ROBOT.2000.844107},
  file = {thesis/literature/zotero/data/storage/WW8FF8QM/Bohlin and Kavraki - 2000 - Path planning using lazy PRM.pdf},
  organization = {{IEEE}}
}

Actual behavior:

@inproceedings{bohlin2000path,
  title = {Path Planning Using Lazy {{PRM}}},
  booktitle = {Proceedings 2000 {{ICRA}}. {{Millennium}} Conference. {{IEEE}} International Conference on Robotics and Automation. {{Symposia}} Proceedings (Cat. {{No}}.{{00CH37065}})},
  author = {Bohlin, R. and Kavraki, L. E.},
  date = {2000-04},
  volume = {1},
  pages = {521-528 vol.1},
  issn = {1050-4729},
  doi = {10.1109/ROBOT.2000.844107},
  file = {/Users/goretkin/projects/thesis/literature/zotero/data/storage/WW8FF8QM/Bohlin and Kavraki - 2000 - Path planning using lazy PRM.pdf},
  organization = {{IEEE}}
}

[label-gun[bot]]

It looks like you did not upload an debug report. The debug report is important; it gives @retorquere your current BBT settings and a copy of the problematic reference as a test case so he can best replicate your problem. Without it, @retorquere is effectively blind. Debug reports are useful for both bug analysis and enhancement requests; in the case of export enhancements, I need the copy of the references you have in mind.

If you did try to submit a debug report, but the ID looked like D<number>, that is a Zotero debug report, which I cannot access. Please re-submit a BBT debug log by one of the methods below.

This request is much more likely than not to apply to you, too, even if you think it unlikely, and even if it does not, there's no harm in sending a debug log that turns out to be unnecessary. @retorquere will more often than not just end up saying "please send a debug log first". Let's just skip over the unnecesary delay this entails. Sending a debug log is very easy:

1. If your issue relates to how BBT behaves around a specific reference(s), such as citekey generation or export, select at least one of the problematic reference(s), right-click it, and submit an BBT debug report from that popup menu. If the problem is with export, please do include a sample of what you see exported, and what you expected to see exported for these references.

2. If the issue does not relate to references and is of a more general nature, generate an debug report by restarting Zotero with debugging enabled (Help -> Debug Output Logging -> Restart with logging enabled), reproducing your problem, and selecting "Send Better BibTeX debug report..." from the help menu.

Once done, you will see a debug ID in red. Please post that debug id in the issue here.

Thank you!

[goretkin]

BTMK7BEX-euc

[retorquere]

You can turn on this at the cost of losing caching (which isn't as big a deal as it used to be now that I have background exports).

[retorquere]

(the debug ID also gives me a copy of your BBT settings, versions of zotero and plugins, etc, so even if I don't need the log, this gives me a better sense of what context BBT works in)

[goretkin]

Oh, I didn't notice that option. Thanks so much!

On the topic of caches, I am experimenting with keeping my zotero data directory versioned under git (using this to get some meaningful-ish diffs for the sqlite databases, though it's still pretty inscrutable). I ignored the files in $datadir/better-bibtex/cache.* because they were changing often, appearing and reappearing, etc. Do you have any opinion on this, or generally, how to maintain version history?

[retorquere]

You're not really expected to know about the hidden preferences, it's OK to ask here.

There's one sqlite file that may be worth backing up, that holds the citation keys. There's a bunch of json files, those will disappear on start and reappear on shutdown. Those are just caches, I don't see much value in versioning those. They will be automatically rebuilt when missing or corrupted.

If the sqlite file goes missing or corrupted, BBT will rebuild it on start; pinned keys will be retrieved from the extra field, all others will be regenerated. If you did not change the pattern since the keys were generated, and you have nu duplicates (which will have gotten a, b etc postfixes), all keys should generate back to what they were, but there's no hard guarantee on that.

[retorquere]

Does this address your questions?

[goretkin]

Yes, it does. Thank you!