GNOME Bugzilla – Bug 772188
Attached (text) files open with different name
Last modified: 2018-05-22 16:47:38 UTC
Created attachment 336522 [details] test.pdf file corresponding to the test.tex file of this bug report Context: Linux Mageia5, Evince 3.14.2. Consider the following `test.tex' to be compiled with `pdflatex': --8<---------------cut here---------------start------------->8--- \begin{filecontents*}{foo.tex} \documentclass{article} \begin{document} Foo. \end{document} \end{filecontents*} % \documentclass{article} \usepackage{xcolor} \usepackage[color=black]{attachfile2} \begin{document} \textattachfile{foo.tex}{Link to `foo.tex'}. \end{document} --8<---------------cut here---------------end--------------->8--- When open in Evince, the resulting PDF file contains the link "Link to `foo.tex'" that is supposed to open `foo.tex'. But clicking on it will open `foo.tex.xxx' instead, where `xxx' is a random string. The open file has the same content as `foo.tex' but, because of its strange extension, is not open as a `.tex' file by the underlying text editor. Notice that Adobe Reader opens this file with the same name.
This occurs because of the mechanism to create a temporary file, which uses such template. https://git.gnome.org/browse/evince/tree/shell/ev-sidebar-attachments.c#n426
Is there is a specific reason for that?
In Unix, you always need a XXXXXX in the template which get replaces with random chars ensuring the file does not exist (for temp files). However, this template could be at the begining of the filename, like XXXXXX.foo.tex or maybe even foo.XXXXXX.tex. Any of these two would not change the extension of the file.
José, That still would not present the file name 'as is'. The attached file is already stored in evince temporary directory, so I think evince tries to avoid some sort of attack that overwrites a file or something like that. A different solution would be to store the file in a subdirectory XXXXXX, and keeping the file name as is.
AFAIK, the Glib API for making temp files requires the XXXXXX template...
> That still would not present the file name 'as is'. The attached file is already stored in evince temporary directory, so I think evince tries to avoid some sort of attack that overwrites a file or something like that. This way of doing: file stored in evince temporary directory and named 'as is', would be the best solution IMHO.
*** Bug 773098 has been marked as a duplicate of this bug. ***
Created attachment 337862 [details] [review] attachments: Save attachment files in temporary XXXXXX subdirectory In order to present the file name "as is", it makes evince store its temporary attachment inside a XXXXXX subdirectory instead of the previous approach of concatenating XXXXXX to the file name.
Isn't the whole idea behind temp directories with unique names (g_dir_make_tmp()) to allow arbitrary collections of files with specified names?
(In reply to jvromans from comment #9) > Isn't the whole idea behind temp directories with unique names > (g_dir_make_tmp()) to allow arbitrary collections of files with specified > names? You are right... this part of the code is old, so probably it existed before g_dir_make_tmp was added to GLIB. Since we are requiring Glib 2.36, we probably could update the code to use this func.
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/evince/issues/711.