[tex-live] Bug in TexLive 2005 and 2007? Non-writable aux-file
George N. White III
gnwiii at gmail.com
Sun Mar 11 20:35:18 CET 2007
On 3/11/07, Hans Hagen <pragma at wxs.nl> wrote:
> David Kastrup wrote:
> > Taco Hoekwater <taco at elvenkind.com> writes:
> >> David Kastrup wrote:
> >>> This is basically a single application on a single operating system
> >>> phenomenon (Acrobat reader on Windows).
> >> Near everybody in the real world out there uses Windows (either
> >> by choice or because of policy decisions), and almost all of those
> >> users use Acrobat reader to look at PDFs.
> >> The Reader is a badly designed program, but unless you know of an
> >> alternative that can display PDFs with the same quality and same
> >> extensive feature set, we are stuck with it.
> > I think it makes no sense to design a user interface that makes
> > dealing with a single program on a single platform easier. If we want
> > to accommodate a single program, the solution is to use the DDC (or
> > whatever they are called) interfaces to the _program_ and close and
> > reopen the viewed file automatically, rather than redesigning the
> > interface to the human because of that single-use case and pretend
> > that it is a generally sane approach.
> to me a file bing locked for writing is not that weird a concept, and
> although it happens to be the case on windows with acrobat, it might as
> well happen with unix when there had been a viewer that does some
> caching (not unthinkcable for 400 mb files) or wants users to signal
> that an opened files to be overwritten. If you wonder why ... on some
> occasions acrobat will repair a damaged file and may ask a user to save
> the repaired file first which also will lock the file; talking of
> locking ... even another (pending or aborted) tex job can have a pdf
> file open ...
*X is fundamentally different because an open file is connected via
the inode -- once you have found the inode you no longer care what it
is called. As long as you keep the inode open, the original contents
remain available despite what other processes might do (short of
crashing the system). Some unix applications that write large files
will pre-allocate space to ensure that they will have a place to put
output when the time comes. There are pdf documents that would
benefit from this (e.g., if \pdfdraftmode could generate an estimate
of the final file size and cache the value for future use).
> and, as taco mentions ... there is a lange amount of users out there on
> anyway, why do we always end up with discussing non relevant operating
> system issues on this list
They are relevant because they are key to making things work smoothly
across the range of platforms. I think supporting Windows is an
unsolved problem -- not just for TeX, but for many open source
projects and small commercial projects (Y&Y).
It is a fact of life for many projects of interest to TeX users
(ghostscript, xpdf, GNU tools, emacs, SciTE, gimp, cinepaint,
inkscape, etc.) that the user communities are overwhelmingly using a
platform that the authors don't use on a daily basis.
> if the openers/writers in web2c cannot be made to distinguish between
> file types (in particular the output file) then that should be fixed,
> and we should not hide ourselved beyond generic
In the long run, it is unwise to rely on error handlers to deal with
"normal" situations --
as this thread confirms, error handling is usually hard, poorly
tested, not portable, and rarely helpful to users. Rather than a
quick fix to make it easier for Windows users to retry after closing
the file in Adobe Reader, it would be much better to ensure that the
problem can't occur. For many Windows users, the editor (e.g.,
WinEDT) or a wrapper script already does the work of telling Adobe
Reader to close the file (but when I tried this using pdfclose in
emacs, the emacs process hung on 100% CPU).
George N. White III <aa056 at chebucto.ns.ca>
Head of St. Margarets Bay, Nova Scotia
More information about the tex-live