[closed] Regression: BibLaTeX export to paths with special characters hangs
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
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
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.)
@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?
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.
And yes, you'll need to try this with the official tarball.
Within that environment, the downloaded binary from zotero.org is executed though.
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.
> 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.
Thank you for your time (=