for MikTeX 2.8 users | possible bug
coo...@nospam.verizon.net
this newsgroup).
I just upgraded my 2.8 install, and now am completely unable to compile
any file that uses \include to include individual subfiles (in my case,
individual chapters of a large book). When I try to compile, I now get
an error message that looks like the following:
!I can't write
on file `../chapter5/chapter5.aux'.
\@include ...\immediate \openout \@partaux #1.aux
Please type another output name:
I have this problem whether or not I compile from within WinEdt (my
usual environment), or from the CLI. I have no problems compiling files
that don't have other files \included (from WinEdt or CLI).
The files I'm working with all compiled *perfectly* before I did the
upgrade this morning - looks like a bunch of runtime upgrades and such.
Whatever got upgraded broke something pretty major.
I confirmed this on 2 other machines (same OS), both with MikTeX 2.8 on
them. On both machines, compilation of files with \include worked fine.
However, as soon as I applied the most recent update, get the error
messages (so, 3 of 3 machines). Tried a complete reinstall of 2.8 on one
of the machines - didn't solve the problem. So, it isn't a problem
created by the update - its something fundamental to the last 2.8 build.
So, it seems pretty definite that the latest 2.8update breaks something
fundamental. Major bug, it would seem...
Perhaps skip the upgrade until this gets worked out?
Joseph Wright
Christian Schenk has posted to the MiKTeX list about this. He's
tightened up on security:
This is a side-effect of a change I made last week: relative and
absolute path names are no longer allowed when using the \openout
directive.
This article (to be published next week) was the trigger for the bug
fix:
http://www.usenix.org/event/leet10/tech/techAbstracts.html#Checkoway
You can get the old (unsafe) behavior by setting this environment
variable:
set MIKTEX_ALLOWUNSAFEOUTPUTFILES=1
The bug fix was applied to the 2.7 binaries too.
Think I should publish publish this on the issues page.
--
Joseph Wright
Peter Flynn
[...]
> Christian Schenk has posted to the MiKTeX list about this. He's
> tightened up on security:
>
>> This is a side-effect of a change I made last week: relative and
>> absolute path names are no longer allowed when using the \openout
>> directive.
As I understand it, path names have to be either relative or absolute. I
don't know any other types. The effect of this seems therefore to imply
that only filenames are allowed (a form of relative path, meaning "in
the current directory"). Is this correct?
///Peter
coo...@nospam.verizon.net
Meaning, we now do...what? I have a very large number of big documents
that are all structured like the following:
\includeonly{../lect1&2/lect1_book,../lect1&2/lect2_book,../lect3&4/lect3_book,../lect3&4/lect4_book,
../lect5&6/lect5_book,../lect5&6/lect6_book,../lect7&8/lect7_book,../lect7&8/lect8_book,../lect9&10/lect9_book,
../lect9&10/lect10_book,../lect1&2/intro_book,../lect11&12/lect11_book}
% +==============================+
% | now we start the document... |
% +==============================+
\begin{document}
% use following to set chapter number for individual chapters
% use n-1 for chapter n
\setcounter{chapter}{0}
%\maketitle
\frontmatter
\include{../lect1&2/intro_book}
\mainmatter
\include{../lect1&2/lect1_book}
\include{../lect1&2/lect2_book}
\include{../lect3&4/lect3_book}
\include{../lect3&4/lect4_book}
\include{../lect5&6/lect5_book}
\include{../lect5&6/lect6_book}
\include{../lect7&8/lect7_book}
\include{../lect7&8/lect8_book}
\include{../lect9&10/lect9_book}
\include{../lect9&10/lect10_book}
\include{../lect11&12/lect11_book}
\end{document}
So, I'm obviously using relative paths in the \include statements. Does
the recent change mean I'm going to have to change all of these to
absolute paths? What about \includegraphics? I have thousands, all of
which use relative paths?
coo...@nospam.verizon.net
>
> Christian Schenk has posted to the MiKTeX list about this. He's
> tightened up on security:
>
OK - so now what do we do, if both absolute and relative paths are
problematic (and according to the note, not allowed). What other sorts
of paths are there? Relative and absolute are basically your choices.
coo...@nospam.verizon.net
>
> You can get the old (unsafe) behavior by setting this environment
> variable:
>
> set MIKTEX_ALLOWUNSAFEOUTPUTFILES=1
>
I can confirm that this (above) works. I'm still puzzled (very) as to
what the preferred solution is - if it ain't relative, or even absolute
paths, what are the alternatives?
Joseph Wright
> As I understand it, path names have to be either relative or absolute. I
> don't know any other types. The effect of this seems therefore to imply
> that only filenames are allowed (a form of relative path, meaning "in
> the current directory"). Is this correct?
>
> ///Peter
I'm going to ask Christian! TeX Live restricts \openout so that it
only works within the current structure. So a path such as "includes/
newfile.tex" is okay, but "../newfile.tex" is not. This seems to me
like a sensible balance between security and realism.
--
Joseph Wright
Joseph Wright
wrote:
> I'm going to ask Christian! TeX Live restricts \openout so that it
> only works within the current structure. So a path such as "includes/
> newfile.tex" is okay, but "../newfile.tex" is not. This seems to me
> like a sensible balance between security and realism.
> --
> Joseph Wright
Testing, that is exactly what MiKTeX now does. You should therefore
have all of your files in one directory:
mainfile.tex
includes/file1.tex
includes/file2.tex
(If you work cross-platform, as I do, then you have to do this anyway
to work with TeX Live on Unix.)
--
Joseph Wright
Ulrike Fischer
coo...@NOSPAM.verizon.net:
Chistian meant relative pathes which moves to parent directories.
Relative pathes which moves to subdirectories of the current folder
still work fine.
This is similar to the security setting used by dvips and by texlive
(where the default for openout is "paranoid").
I think it is very good that miktex has this security setting now
too, it is not a good idea to allow an application to write files in
parent directories.
--
Ulrike Fischer
Peter Flynn
No indeed, but it should allow users to *read* files which live in
parent directories or children of them.
///Peter
Ulrike Fischer
>>>> Christian Schenk has posted to the MiKTeX list about this. He's
>>>> tightened up on security:
>>
>>> OK - so now what do we do, if both absolute and relative paths are
>>> problematic (and according to the note, not allowed). What other sorts
>>> of paths are there? Relative and absolute are basically your choices.
>>
>> Chistian meant relative pathes which moves to parent directories.
>> Relative pathes which moves to subdirectories of the current folder
>> still work fine.
>>
>> This is similar to the security setting used by dvips and by texlive
>> (where the default for openout is "paranoid").
>>
>> I think it is very good that miktex has this security setting now
>> too, it is not a good idea to allow an application to write files in
>> parent directories.
>
> No indeed, but it should allow users to *read* files which live in
> parent directories or children of them.
Sure but reading from parent directories still works fine. The
problem with \include is that it not only tries to read a file but
also to write an .aux-file in the parent directory and this writing
is now disabled and so gives an error.
--
Ulrike Fischer
Martin Hehn
> Am Sat, 01 May 2010 16:40:20 +0100 schrieb Peter Flynn:
>
>
>
> >>>> Christian Schenk has posted to the MiKTeX list about this. He's
> >>>> tightened up on security:
>
> >>> OK - so now what do we do, if both absolute and relative paths are
> >>> problematic (and according to the note, not allowed). What other sorts
> >>> of paths are there? Relative and absolute are basically your choices.
>
> >> Chistian meant relative pathes which moves to parent directories.
> >> Relative pathes which moves to subdirectories of the current folder
> >> still work fine.
>
> >> This is similar to the security setting used by dvips and by texlive
> >> (where the default for openout is "paranoid").
>
you might be able to have the aux files produced in the current or
subdirectory with the --aux-directory=dir option passed on to
(pdf)latex. worth a try if you are not keen to change your current
file management