[Bug libc/13047] New: On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[Bug libc/13047] New: On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[lsatenstein at yahoo dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

           Summary: On 32 bit system (UBUNTU Natty) Cannot open a file of
                    size 5GB
           Product: glibc
           Version: unspecified
            Status: NEW
          Severity: critical
          Priority: P2
         Component: libc
        AssignedTo: drepper.fsp@gmail.com
        ReportedBy: lsatenstein@yahoo.com


I created a large file that I truncate to 5GB via Truncate command.

I get a NULL return from  fopen("bigfile","rb"); where bigfile is 5GB exactly.

It will work with smaller files 2.5GB. 

Create file with 
truncate -s 5GB bigfile



The function works ok on Debian Squeeze, but not on UBUNTU.  (both are 32bit
versions).  I have not confirmed that it works on Fedora 32bit. 

fopen() works fine with 64bit linux.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[lsatenstein at yahoo dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

--- Comment #1 from Leslie Satenstein <lsatenstein at yahoo dot com> 2011-07-31 01:11:42 UTC ---
Large DVD Iso files can't be copied.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[aj at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

Andreas Jaeger <aj at suse dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aj at suse dot de
         Resolution|                            |INVALID

--- Comment #2 from Andreas Jaeger <aj at suse dot de> 2011-07-31 18:57:27 UTC ---

Not a bug in glibc but a limitation of a 32-bit system unless you use the
proper interfaces, see for example this web page:
http://www.suse.de/~aj/linux_lfs.html

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[lsatenstein at yahoo dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

Leslie Satenstein <lsatenstein at yahoo dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #3 from Leslie Satenstein <lsatenstein at yahoo dot com> 2011-07-31 23:24:23 UTC ---
Here is my come-back. Since one can add a #define to allow using buffered IO
(fread, fwrite, etc) for files in excess of 2 gigabytes. then this define
should be permanent within stdio.h .  I wanted to read an ISO DVD and could
not.   I would refer the owner of this maintenance problem to the actual
libc.pdf file section 4.17, which makes no mention of the #define.  (However in
respoonse to Andreas Jaeger, personal reply (which I appreciate receiving and
for which I thank him), using the search of the libc.PDF I did find a chapter
about large file support.  

Something is wrong when today a large file is one measured in petabytes. Please
redirect this topic and this bug to the documentation project and of course to
a steering committee to update the stream IO functionality to handle very large
files, or to state that in the libc.pdf fopen() document, to refer to the large
file section.

I lost quite a few hours of digging to independently discoover the #define that
enables large file support.  I would also ask why large file support is turned
on for 64 bit linux?  Had 64 bit linux the same constraint, I would have not
been concerned.  (I was porting code from 64bit to 32bit), for older systems.

Thank you again Andreas, for the prompt reply.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[aj at suse dot de]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

Andreas Jaeger <aj at suse dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Andreas Jaeger <aj at suse dot de> 2011-08-01 07:21:49 UTC ---
This is how POSIX defines it. Changing it is not possible without breaking
programs.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bugdal at aerifal dot cx

--- Comment #5 from Rich Felker <bugdal at aerifal dot cx> 2011-08-07 17:56:48 UTC ---
Please reopen and rename this bug. It should be called "It's 2011 and
-D_FILE_OFFSET_BITS=64 is still not the default." Seriously, the attempt at
coexistence between programs compiled correctly and a few that mistakenly
omitted -D_FILE_OFFSET_BITS=64 is an endless source of subtle bugs - for
instance if a 32-bit-offset program inherits a file descriptor from a
64-bit-offset one, which happens basically anytime a properly built shell runs
a 32-bit-offset program.

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[bugdal at aerifal dot cx]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

Rich Felker <bugdal at aerifal dot cx> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |

--- Comment #6 from Rich Felker <bugdal at aerifal dot cx> 2012-05-14 04:22:36 UTC ---
As per my comment last year, I think this issue merits revisiting. Since the
intended protections against bad behavior/file corruption break down when file
descriptors are inherited between programs built with differing values for
_FILE_OFFSET_BITS, and since it's now 2012, I think there's a strong argument
to be made for making 64-bit off_t the default. I know a small but persistent
number of programs on Debian and other mainstream dists are still built without
any attention to _FILE_OFFSET_BITS, and this leads to broken corner case
issues. Fixing this at the libc level makes a lot more sense than fixing it in
every single program...

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] On 32 bit system (UBUNTU Natty) Cannot open a file of size 5GB

[joseph at codesourcery dot com]

http://sourceware.org/bugzilla/show_bug.cgi?id=13047

--- Comment #7 from joseph at codesourcery dot com <joseph at codesourcery dot com> 2012-05-14 10:55:19 UTC ---
Note that using _FILE_OFFSET_BITS=64 introduces namespace issues for which 
I've filed bug 14106 (although hopefully not many real programs actually 
do anything that would be affected by those issues).

-- 
Configure bugmail: http://sourceware.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

[Bug libc/13047] Make 64-bit off_t the default on i386 and others

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13047

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |fweimer at redhat dot com
            Summary|On 32 bit system (UBUNTU    |Make 64-bit off_t the
                   |Natty) Cannot open a file   |default on i386 and others
                   |of size 5GB                 |
           Severity|critical                    |normal

-- 
You are receiving this mail because:
You are on the CC list for the bug.

[Bug libc/13047] Make 64-bit off_t the default on i386 and others

[fweimer at redhat dot com]

https://sourceware.org/bugzilla/show_bug.cgi?id=13047

Florian Weimer <fweimer at redhat dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
              Flags|                            |security-

-- 
You are receiving this mail because:
You are on the CC list for the bug.