Second build fails when using an output directory.

[phyllisstein]

Hey there! I'm experiencing an odd issue with the latest version of this package. I have it configured to build into .latex, and that's been fine in the past, but as of the latest update, the first build will run successfully and all subsequent builds will fail. The build promise is rejected with status 0 and nothing is copied, that is, but the file in .latex is rebuilt. Deleting the .pdf and .synctex.gz files in the folder above .latex, into which they're copied on successful builds, allows the build to proceed.

Thanks in advance for your help, and thanks for all your hard work on this package!

[thomasjo]

Does this happen with all TeX files? For instance, does it happen with something as simple as this

\documentclass{article}
\begin{document}
...
\end{document}

If that fails, it'd be great if you could copy the contents of the produced log file into a Gist.

In addition, what OS are you running, and what distribution of TeX are you using?

[phyllisstein]

Sure thing! I'm running a developer preview of MacOS 10.10.4, and using MacTeX. latexmk is at version 4.39, and XeLaTeX at version 3.14159265-2.6-0.99991. As before, the simple test file wasn't copied from the build folder after the first build and atom-latex reported failure, though the log file (https://gist.github.com/phyllisstein/4aca1d78ead0804ca182) reported that it was successful.

[thomasjo]

Thanks for the update—just to rule out any potential interference with Dropbox, can you see if you can reproduce the problem when working in a folder not managed by Dropbox. E.g. a folder on your Desktop or similar.

[phyllisstein]

I saw the same results using a folder on my Desktop: the first build was successful, the second failed, apparently at the stage of moving the output out of the build directory. I updated the gist with a new log (https://gist.github.com/phyllisstein/4aca1d78ead0804ca182#file-second-test-log) and took a screenshot of the compilation error:

Let me know if I can do anything else to help troubleshoot!

[thomasjo]

I've managed to reproduce this. There was a breaking change introduced in atom/fs-plus@c3ec708 that is causing the problem. Trying to find a sensible workaround right now.

[thomasjo]

I just released a patch release (v0.23.3) that should resolve this problem.

[phyllisstein]

That works great! Thanks so much for looking into this; I really appreciate your taking the time.