GNOME Bugzilla – Bug 724556
Build tools fail on gvfs-mounted path
Last modified: 2014-03-05 14:34:30 UTC
Using LaTeXila 2.8.3, the build tools fail when the currently-open file is located in a SMB share mounted by gvfs. The error window shows "Failed to change to directory 'smb://[ip-address]/[sharename]/[path]' (No such file or directory)". This share is mounted in the filesystem at /run/user/1000/gvfs/smb-share:server=[ip-address],share=[sharename]/[path]. Running pdflatex or bibtex from the terminal produces the expected result (a correctly-compiled pdf or bbl file, respectively). I'm using Cinnamon, which currently has GTK 3.8, so I can't test this on LaTeXila 2.10 at present as it has a dependency on 3.10.
Thank you for the bug report. I suppose you use latexmk in latexila. Can you run the same latexmk command in a terminal? If you configure the build tools in latexila to use the "all-output" post-processor (instead of the latexmk post-processor), do you have more information?
Thanks for your consideration. In fact, I normally use pdflatex in latexila, but I've tried the latexmk build option as well; it fails with an identical error message. In the terminal, however, both function correctly. For reference, the commands are latexmk -pdf -synctex=1 [myfile].tex pdflatex -interaction=nonstopmode -synctex=1 [myfile].tex To successfully compile, I cd to the correct path (the one in my previous message, beginning with /run/user/...) and execute either of the above commands. No more information is output to the error window with "all-output". My suspicion in light of the above is that before executing the command for the selected build option, latexila attempts to set the working directory somehow, but is passing the URI-style path to a function that expects the path as mounted in the filesystem. Thus the error message is the same across the different build tool selections, because it is in fact generated by the same change-working-directory function. After briefly poking about in the code, it looks like the directory string is obtained from File.get_parent().get_parse_name() in build_job_runner.vala and passed to Process.spawn_async_with_pipes() in build_command_runner.vala. Looking up the relevant literature on valadoc.org, I see that get_parse_name() is specified to give a parse_name (which unfortunately is recursively defined to be the thing you get out of get_parse_name). Another method, get_path(), is specified to return the local pathname; might this be more appropriate?
I recompiled version 2.8.3 with get_parse_name changed to get_path in line 64 of build_job_runner.vala, and the problem appears to be solved. I haven't found this to break anything, but to be honest I didn't poke around too much. If it doesn't work, I'll revert back.
Good investigation. If what you say is good, the patch is really simple. Since there are some students interested to work on latexila for the GSoC, I'll keep this bug open so a student can write the commit, send it here as attachment, etc. It's a good exercise. (but it would obviously not be sufficient for applying to the gsoc).
Excellent; in the meantime, I'll use my locally-modified version. There's a number of other places in the code where get_parse_name() is called-- it would be nice if whoever works on this at the GSoC figures out which of them ought to be changed and which left alone.
> I recompiled version 2.8.3 with get_parse_name changed to get_path in line 64 > of build_job_runner.vala, and the problem appears to be solved. Build tool will work correctly, but other commands invoking shell e.g. clean-up tool still have this problem.
> Build tool will work correctly, but other commands invoking shell e.g. clean-up > tool still have this problem. Clean-up tool works fine without any change. > Excellent; in the meantime, I'll use my locally-modified version. There's a > number of other places in the code where get_parse_name() is called-- it would > be nice if whoever works on this at the GSoC figures out which of them ought to > be changed and which left alone. I have checked these get_parse_name() in src/*.vala. These get_parse_name() are used for getting file/directory's full-path to build shell command, set dialog's labels and filter log, but get_parse_name() will return URI not a full-path when the file is not a local file. In the patch, I just replace all get_parse_name() with get_path() and change two variables in src/project_dialogs.vala line 341-344 to fit get_path(). Everything goes well, please review.
Created attachment 270111 [details] [review] Replace get_parse_name with get_path
Review of attachment 270111 [details] [review]: For displaying the filename, I think it's better to keep get_parse_name(). The URI has more meaningful information for a remote file. So when the filename is added to a string or used with replace_home_dir_with_tilde(), keep get_parse_name(). For the other ones, it makes sense to use get_path(). There should be a longer commit message explaining why the change was needed, to summarize the problem described in this bug report. In the commit title, no need to mention src/*.vala, and please add parenthesis after a function name, so we better see that it is a function (like I've done in this comment).
> Review of attachment 270111 [details] [review]: > > For displaying the filename, I think it's better to keep get_parse_name(). The > URI has more meaningful information for a remote file. > So when the filename is added to a string or used with > replace_home_dir_with_tilde(), keep get_parse_name(). > For the other ones, it makes sense to use get_path(). Thanks for reviewing. The only necessary change is string working_directory, it seems only spawn_async_with_pipes() need a local full-path. > There should be a longer commit message explaining why the change was needed, > to summarize the problem described in this bug report. > In the commit title, no need to mention src/*.vala, and please add parenthesis > after a function name, so we better see that it is a function (like I've done > in this comment). Thank you for reminding me, I'll certainly be more careful.
Created attachment 270150 [details] [review] Fix working directory when build remote file
Review of attachment 270150 [details] [review]: Thank you, I've pushed the commit.