[closed] Regression: BibLaTeX export to paths with special characters hangs

edited May 8, 2019
Debug Report ID: D1971398252

Recently, Zotero exports that have worked previously started to hang: When exporting a collection as BibLaTeX to a path containing special characters (in my case a "ß"), the export hangs infinitely long. When exporting the same collection to a path consisting only out of ASCII characters, the export works just fine.

The log shows the following exception: [JavaScript Error: "Component returned failure code: 0x80520012 (NS_ERROR_FILE_NOT_FOUND) [nsIFileOutputStream.init]" {file: "chrome://zotero/content/xpcom/translation/translate_firefox.js" line: 950}]

**How to reproduce**:

1. Create two directories "dir_ascii" and "dir_with_ß"
2. Export your collection as BibLaTeX with notes: right click on library -> Export library -> Export Notes and in UTF-8
3. Do this export first to "dir_ascii" and then to "dir_with_ß"
4. Observation: first export succeeds, second export hangs and never finishes

I deem this to be a regression as exports to the directory with special characters used to work before. Unfortunately, rolling back to an earlier version (5.0.58) that used to work does not fix this issue though.

I usually use the Better-BibTeX export add-on and discovered this issue while trying to debug export problems with that add-on. It turned out that not only the add-on export was broken but the standard Zotero BibLaTeX is too, and that the latter is the root cause.
See the Better-BibTeX issue for more logs https://github.com/retorquere/zotero-better-bibtex/issues/1180
  • Unfortunately, rolling back to an earlier version (5.0.58) that used to work does not fix this issue though.
    That would suggest this wasn't a regression in Zotero.

    Exporting to Unicode directories works for me on macOS and Ubuntu, so unless other people can reproduce this, this is likely something specific to your system/filesystem. (This also wouldn't be specific to BibLaTeX — this is just the initial file write/create/truncate call for any export format.)
  • @schmittlauch this is on Linux, right? Which distro?
  • @adamsmith Yes, Linux, more precisely NixOS 19.03. The same package can be installed on other Linux distributions using the Nix package manager.

    @dstillman I am confused about this, too. Could it be that some existing state (within the Zotero DB or config files) is causing this? I could try to start with a clean installation.

    What'd be the best way to export and then re-import all entries, files and notes?
    Also, does the exception from the debug log tell anything?
  • how exactly are you installing Zotero?
    We'd want this replicated with a version run straight from the extracted tarball from zotero.org/download . All packages are provided by third parties and while they're usually fine, this wouldn't be the first time a package included a bug not present in Zotero proper.
  • What'd be the best way to export and then re-import all entries, files and notes?
    Definitely don't do that. This has nothing to do with your data.

    And yes, you'll need to try this with the official tarball.
  • @adamsmith Running the binary download directly under NixOS is not possible, as it has a different library environment then other linux distros. So it is wrapped in an environment containing all its necessary run-time dependencies.
    Within that environment, the downloaded binary from zotero.org is executed though.
  • @dstillman What i want to achieve is being able to start again from a clean installation and clean user data/ library, but without loosing my current collections (or at least able to get them back).
  • This is clearly something about that package or the system that runs it, then. I'm afraid we can't help with that.
    What i want to achieve is being able to start again from a clean installation
    Why? I'm saying that this error is a problem on your system that doesn't have anything to do with your Zotero library, and it would be pointless to erase your data and import it back in a lossy format to try to fix this problem.
  • See https://www.zotero.org/support/zotero_data for how to backup and restore Zotero data.
    But I'd start looking at this at the NixOS level, either at the package or at the environment, given that this isn't an issue on other *nix systems. I'm very skeptical that filepath handling would in any way be affected by state, flags, etc.
  • edited May 8, 2019
    @dstillman

    > This is clearly something about that package or the system that runs it

    May I ask why you are so sure about this? Yes, that is entirely possible, but the NixOS packaging is as close to "running the official tarball" as it can get given the necessary adjustments for it to actually run on NixOS.

    https://github.com/NixOS/nixpkgs/blob/9e6740c7ad610abba13a40f02d5eac93874b8bc8/pkgs/applications/office/zotero/default.nix

    If you're almost certain about this being caused by the packaging, I can totally understand that you do not want to spend time on debugging such a niche issue. If you have any useful pointers for me debugging this myself I'd be grateful to get them, though.
  • Nevermind, it actually was a packaging issue (although I still do not know why it ever worked before).

    Thank you for your time (=
Sign In or Register to comment.