This service will be undergoing maintenance at 00:00 UTC, 2016-09-28. It is expected to last about 1 hours
Bug 71507 - Files larger than 2Gb not supported
Files larger than 2Gb not supported
Status: CLOSED RAWHIDE
Product: Red Hat Linux
Classification: Retired
Component: libtiff (Show other bugs)
7.2
i386 Linux
medium Severity medium
: ---
: ---
Assigned To: Phil Knirsch
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2002-08-14 11:17 EDT by Toralf
Modified: 2015-03-04 20:11 EST (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2002-08-19 05:18:57 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


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

  None (edit)
Description Toralf 2002-08-14 11:17:19 EDT
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):
3.5.5-13
- 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 04:14:06 EDT
Created attachment 70784 [details]
Enable 64-bit I/O
Comment 2 Toralf 2002-08-15 04:27:46 EDT
Attached patch should fix this problem. I have created, then viewed a 2.6Gb
(32000 by 28000 pixels RGB) file with this code.

Notes:
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 05:18:52 EDT
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 09:09:08 EDT
OK, latest rawhide version of libtiff contains your fix.

Thanks again,

Read ya, Phil
Comment 5 Toralf 2002-08-21 04:59:08 EDT
Good. Thanks for the quick response!

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