Bug 71507 - Files larger than 2Gb not supported
Summary: Files larger than 2Gb not supported
Alias: None
Product: Red Hat Linux
Classification: Retired
Component: libtiff   
(Show other bugs)
Version: 7.2
Hardware: i386 Linux
Target Milestone: ---
Assignee: Phil Knirsch
QA Contact:
Depends On:
TreeView+ depends on / blocked
Reported: 2002-08-14 15:17 UTC by Toralf
Modified: 2015-03-05 01:11 UTC (History)
1 user (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2002-08-19 09:18:57 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Enable 64-bit I/O (855 bytes, patch)
2002-08-15 08:14 UTC, Toralf
no flags Details | Diff

Description Toralf 2002-08-14 15:17:19 UTC
Description of Problem:
TIFF is supposed to support images with raster data size to 4Gb, but libtiff is
actually unable to write files larger than 2Gb, presumably because "large file"
support is not enabled for I/O operations/

Version-Release number of selected component (if applicable):
- and also 3.5.7-2 on RedHat 7.3, I believe.

How Reproducible:
Every time.

Steps to Reproduce:
1. Write tiff file >2Gb but <4Gb... Not sure what's the easiest way. 
   'tiffcp <lots of files> out.tif', perhaps.

Actual Results:
Filesize limit exceeded (core dumped)

Expected Results:
TIFF file created

Additional Information:
This is a major issue to us even given the 4Gb limitation of the TIFF format as
 the output from scanning a typical map or drawing (which is what we do) in RGB
at 1000dpi has a size of between 2 and 3Gb.

I am working on a patch right now.

Comment 1 Toralf 2002-08-15 08:14:06 UTC
Created attachment 70784 [details]
Enable 64-bit I/O

Comment 2 Toralf 2002-08-15 08:27:46 UTC
Attached patch should fix this problem. I have created, then viewed a 2.6Gb
(32000 by 28000 pixels RGB) file with this code.

1. _LARGEFILE64_SOURCE (which in turn defines __USE_LARGEFILE64) + O_LARGEFILE
was not enough; write appeared to be successful with these, but the resulting
file was not valid. Instead, full(er) 64-bit support had to be enabled via
#define _FILE_OFFSET_BITS 64
Hopefully, this won't hurt performance too much.

2. tiffdump still won't handle >2Gb files as it uses direct (signed 32-bit)
open() rather than (now 64-bit) libtiff functions. Of course, it could easlily
be updated in a similar manner.

3. I'm right now trying to find out what happens when the 4Gb limit is reached.

Comment 3 Phil Knirsch 2002-08-19 09:18:52 UTC
Wow, thanks for the detailed report and fix.

I'll certainly include it in the next libtiff build i'm doing.

Read ya, Phil

Comment 4 Phil Knirsch 2002-08-19 13:09:08 UTC
OK, latest rawhide version of libtiff contains your fix.

Thanks again,

Read ya, Phil

Comment 5 Toralf 2002-08-21 08:59:08 UTC
Good. Thanks for the quick response!

Note You need to log in before you can comment on or make changes to this bug.