0

Occasionally, when running xelatex (using TeX Live 2018 on Linux Mint 19.2), I encounter the following error message:

(/usr/local/texlive/2018/texmf-dist/tex/latex/microtype/mt-cmr.cfg))
(/usr/local/texlive/2018/texmf-dist/tex/generic/oberdiek/se-ascii-print.def) [1
! I can't write on file `xxx.pdf'.
(Press Enter to retry, or Control-D to exit; default file extension is `.pdf')
Please type another file name for output:

This happened to me yesterday evening, and I found myself expending an hour of my time trying to nail down what could be causing causing such a behavior.

I had a document viewer with the PDF open so naturally that could have been blocking access to the file so I closed the program, but to no avail (I'm using Evince which is most of the time fine, does automatically reload on document update, but has also occasionally been known to become unresponsive for no tractable reason).

I tried then to remove all temporary files and the PDF from the target folder; in my case this included all files matching *.aux, *.fls, *.log, *.out, and *.pdf; this had no discernible effect.

I also tried to write to another target:

(Press Enter to retry, or Control-D to exit; default file extension is `.pdf')
Please type another file name for output: /tmp/x.pdf
! I can't write on file `/tmp/x.pdf'.
(Press Enter to retry, or Control-D to exit; default file extension is `.pdf')

This did not spark joy.

During my continued efforts to come to grips with this I could produce a PDF roughly one out of two or three runs; I was unable to make the behavior predictable—it's not the viewer, it's none of the existing files in the directory, all packages that are loaded are always the exact same ones.

Has there been any experience as to possible reasons for failure to write to the target or any other file? If the specific target had been blocked, then surely entering a non-existing filename in the existing /tmp directory should always work, right? It feels as if the 'file writing mechanism' of TeX has a washer hopping around in the gear, sometimes causing it to grind to a halt.

I will say that this work is being done on a recent but not terribly performant netbook, IOW it might be the case that shortage of RAM is the underlying problem and failure to write just the visible side effect of that. Maybe someone can corroborate or refute that; personally I would of course prefer any software to fail with an Out of Memory error when that is indeed the problem.

John Frazer
  • 345
  • 1
    this is almost certainly an operating system lock, so it's either the file permissions or a (possibly zombie) process is holding the file, hard to diagnose remotely:-) – David Carlisle Jan 09 '20 at 12:19
  • 1
    with xetex it is xdvipdfmx rather than xetex that writes the pdf so it's possible that in some run xdvipdfmx didn't quit cleanly and is hanging around in the background which could block a second run on the same file. – David Carlisle Jan 09 '20 at 12:21
  • Your theory about low RAM might actually be correct: see https://tex.stackexchange.com/questions/16801/xelatex-i-cant-write-on-file-test-pdf?rq=1 – Disenchanted Lurker Jan 09 '20 at 13:06
  • Somehow my earlier comment disappeared... @DavidCarlisle I could rule out the possibility of it being a lock, it would otherwise be the most likely cause. – John Frazer Jan 09 '20 at 23:21
  • @DisenchantedLurker would you mind making an answer out of your comment so I can go and accept it? – John Frazer Jan 09 '20 at 23:22
  • @JohnFrazer If it is really the same issue, it would be better to close this question as a duplicate of the other one. Otherwise I'd just be repeating what's written there, and that's frowned upon. – Disenchanted Lurker Jan 10 '20 at 07:30

1 Answers1

1

It seems that the problems for this kind of mistake can have varied origins.

Below you can find links to a couple of threads that talk about a similar problem to yours:

I hope you can use them.

Lu Cables
  • 11