Build problem with tex file on network drive under Windows about atom-latextools HOT 6 OPEN

The working directory is set to the directory containing the root file, that is the file latextools builds. If you could post the log or an example of how you are inputting the file, it might shed some light on the issue.

from atom-latextools.

That's the thing. If I use the build command in Atom, it looks like it is OK but it isn't. But since the log file still is there, it parses the log file from a previous build and shows that there are no errors. If I take the build command and use it in the CMD (being in the directory of the tex file) it works.

This command is used:
texify -b -p --engine=luatex --tex-option="--synctex=1" "2016-04-14_1st-session_1st-day_edited.tex"

Latextools uses exactly this command but produces a message in the texify log:
FATAL texify - The input file could not be found.

So I don't know how the log file of the build could be useful, because Latextools fails with the build command. The command silently fails and the only hint is that it can't parse the log file (if there is none). If there is a log file, it parses that and if you only made minor changes you don't even notice until later that there actually was no build happening.

from atom-latextools.

I guess I found the problem. The directory is on a network drive. In the CMD I use the drive letter in the path. But latextools uses the \\Server notation and texify most likely doesn't understand that path. Therefore in case of a network drive on Windows, the drive letter should be used instead of the \\Server notation.

Edit:
I can confirm that this is the issue. I have manually changed the builder.coffee file and replaced the problematic part hardcoded and now it works.

from atom-latextools.

Hmmmmm... Where do you see the \\server bit show up? We're not doing anything to intentionally resolve drive letters to UNC paths so it would be helpful to track down where this is happening...

from atom-latextools.

So I tried this out and, you're right, there's an issue when using UNC paths, but I can only recreate the issue when the project folder is added to Atom using the UNC path instead of the drive letter mapping. If you already have the path mapped to a drive letter, it would be easier just to open the folder using the drive letter path rather than the UNC path.

from atom-latextools.

Digging a little deeper, the problem has nothing to do with texify itself or even latextools exactly. The problem is that the builders run the command using child_process.exec, which uses the shell (cmd.exe, in the case of Windows) to interpret the command into a process call. This has the advantage that the commands supplied from latextools go through the same processing as commands run from the command line, so the process is a little more straight-forward and more easily replicable using the shell directly. The downside is it suffers the same limitations as the shell. In particular, cmd.exe doesn't support UNC paths as the current working directory (yes, the page is XP-specific, but it holds at least up to Windows 7), so when latextools calls exec, cmd.exe is launched, sees the UNC path, and changes the current working directory to C:\Windows (or, more accurately, %SystemRoot%), hence when texify is launched (by cmd.exe) the file it is looking for doesn't exist, since it was only passed a relative path (using a relative path and changing the current working directory has some advantages as certain LaTeX engines are rather picky about characters in the path; moreover I just don't know if texify does actually support UNC paths).

The upshot is that, as a side-effect, #86 (when its merged) will fix this, since it uses the confusingly-named child_process.execFile function to launch the program, which doesn't rely on the shell. For now, however, if you have the UNC path mounted as a mapped drive, just ensure the tex file is opened by Atom using the mapped drive, and things should work as expected.

from atom-latextools.