Customizing names of auxiliary file: safe practices?

I maintain a package (morewrites) which requires a temporary auxiliary file to function (written and read right away). This auxiliary file is currently named \jobname.mw, and a user has asked me to allow customization because this extension conflicts with some other tool.

My first idea is to provide an interface of the form \morewritessetup{file=...} where ... is replaced by the name the user wants to use.

However, I am worried about users doing \morewritessetup{file=\jobname} by mistake. When my code then writes to the file \jobname, it will clobber the source file \jobname.tex and the user will be very unhappy. This is actually a bigger problem: it would be best to make sure that I am not destroying any of the user's pre-existing files. Unfortunately, I cannot simply check that the file is new before writing it, since that will only be the case the very first time TeX is run on the file.

What is a safe approach?

• Not entirely safe but what about a file name like \jobname-mw.aux? – clemens Jul 26 '14 at 18:04
• Why not only allow a customisable extension instead of the whole name? – Henri Menke Jul 26 '14 at 18:16
• Or just check if the given one is \jobname, and, in that case, throw an error. – Manuel Jul 26 '14 at 19:08
• We had recently a case when \begin{filecontents}{references.bib} destroyed a user's bibliographic database because the filecontents package was loaded. In my gmp package I use \jobname+mp<number>, but of course this still might overwrite a preexisting file. In imakeidx I use the standard .ind extension, so the problem is more limited. Maybe checking if the file starts with some prescribed bytes? If it does, you can assume it has been written in a previous run. – egreg Jul 26 '14 at 19:10
• @egreg I like your last idea, with a first line such as %% File generated by the TeX package morewrites. – Bruno Le Floch Jul 26 '14 at 19:37

1 Answer

TeX by itself doesn't make any check when it's requested to start writing a file. This can have undesired consequences.

For example, using \begin{filecontents}{references.bib} along with \usepackage{filecontents} caused the overwriting of a preexisting bibliographic database with the same name. On an operating system I won't name, doing \include{file.tex} can lead to destruction of file.tex because the system doesn't allow multiple periods in a file name and, when TeX tries to write on file.tex.aux, the OS discards the second extension.

The first problem is solved by avoiding \usepackage{filecontents} unless one is sure it won't overwrite necessary files. The second problem might be solved by fixing \include so that it stops when the argument contains the .tex extension (which shouldn't be used anyway, in this case).

The problem arises whenever an auxiliary file is being written out. In my gmp package, the file names used are \jobname+mp<number> that should be safe enough; for imakeidx I rely on the .idx, .ind and .ilg extensions.

A possible solution for your problem is looking at the first lines of the file that will be overwritten, in case it already exists. If they match a certain pattern, you can be almost certain the file has been created by your package on a previous run.

• At the end of the day, since I do not need the file to keep information between runs, I decided only use the file if it is empty, and empty it every time I am done using it. – Bruno Le Floch Mar 11 '15 at 7:42