I also confirm this bug. This is caused by LFS. I did a lot of testing with pdf inclusion on utah machines before TL release, unfortunately with LFS always disabled so this bug was not detected. Thanh PS: Perhaps TL should have been built with LFS disabled, since this feature is still highly experimental and has been not tested well enough. On Tue, Sep 09, 2008 at 06:03:19AM +0400, Vladimir Volovich wrote:

"NHFB" == Nelson H F Beebe writes:

NHFB> I now have a simple test case that exhibits the problem, and NHFB> experiments show that it manifests itself only on Sun Solaris NHFB> SPARC.

NHFB> On a ZFS system, I see something like this: [...] NHFB> 107T Sep 8 16:38 bug.pdf

NHFB> On a UFS Solaris SPARC system (/var/tmp), I see this:

NHFB> % pdflatex bug.tex ... pdflatex: bug: File too large

i built solaris sparc binaries for texlive, and i can reproduce this behavior too. there is nothing related to ZFS. it only doesn't complain about a big file size, while UFS returns EFBIG (shown by truss):

write(6, " F 1 5 F 1 6 F 1 7 F 1 8".., 8192) = 8192 write(6, "C4CD97 kB29E9C0FF8DFCC B".., 330) = 330 llseek(6, 0x0000330C00000EDC, SEEK_SET) = 0x330C00000EDC write(6, " 4 9 1 6", 4) Err#27 EFBIG

because of a big lseek before the write. maybe it is because of a compiler bug, or maybe it is a pdftex bug. therefore i'm also forwarding to the ntg-pdftex list. does anybody have an idea if it's likely a compiler bug or a pdftex bug?

Best, v.

P.S. for those on nts-pdftex who are not subscribed to texlive list, here is the snippet with a test case: ================================================================= Here is the test file:

% cat bug.tex

\documentclass[]{article}

\usepackage{graphicx}

\begin{document}

This is a picture of a golfer:

\centerline{\includegraphics[width = 0.5\textwidth]{cgolfer}}

\end{document}

The cgolfer.pdf file can be found here:

http://www.math.utah.edu/~beebe/cgolfer.pdf

The bug is unrelated to the particular PDF file that is included as a graphics image.