After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 724556 - Build tools fail on gvfs-mounted path
Build tools fail on gvfs-mounted path
Status: RESOLVED FIXED
Product: gnome-latex
Classification: Other
Component: general
2.8.x
Other Linux
: Normal normal
: unspecified
Assigned To: LaTeXila maintainer(s)
LaTeXila maintainer(s)
Depends on:
Blocks:
 
 
Reported: 2014-02-17 15:33 UTC by Kyle Hird
Modified: 2014-03-05 14:34 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Replace get_parse_name with get_path (9.79 KB, patch)
2014-02-24 11:41 UTC, Chunyang Xu
needs-work Details | Review
Fix working directory when build remote file (1.03 KB, patch)
2014-02-24 15:46 UTC, Chunyang Xu
committed Details | Review

Description Kyle Hird 2014-02-17 15:33:49 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.
Comment 1 Sébastien Wilmet 2014-02-17 18:20:52 UTC
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?
Comment 2 Kyle Hird 2014-02-17 20:01:18 UTC
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?
Comment 3 Kyle Hird 2014-02-17 20:26:26 UTC
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.
Comment 4 Sébastien Wilmet 2014-02-23 17:11:10 UTC
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).
Comment 5 Kyle Hird 2014-02-23 20:23:09 UTC
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.
Comment 6 Chunyang Xu 2014-02-24 08:15:15 UTC
> 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.
Comment 7 Chunyang Xu 2014-02-24 11:41:05 UTC
> 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.
Comment 8 Chunyang Xu 2014-02-24 11:41:24 UTC
Created attachment 270111 [details] [review]
Replace get_parse_name with get_path
Comment 9 Sébastien Wilmet 2014-02-24 14:00:21 UTC
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).
Comment 10 Chunyang Xu 2014-02-24 15:42:29 UTC
> 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.
Comment 11 Chunyang Xu 2014-02-24 15:46:08 UTC
Created attachment 270150 [details] [review]
Fix working directory when build remote file
Comment 12 Sébastien Wilmet 2014-03-05 14:34:12 UTC
Review of attachment 270150 [details] [review]:

Thank you, I've pushed the commit.