Re: [RFC] Copy as much as you can during a 32-bit stat before returning EOVERFLOW?

[Rich Felker <dalias@aerifal.cx>]

On Tue, Feb 26, 2013 at 02:55:33PM -0500, Carlos O'Donell wrote:
> Community,
> 
> There are several filesystems which are going to be switching over
> or already have switched over to unconditional 64-bit inodes and 
> file sizes. This means that the current crop of 32-bit applications
> may not be able to run reliably on these filesystems since stat 
> may return EOVERFLOW for large values.

Can we PLEASE reconsider the decision to keep supporting 32-bit off_t?
If we're to the point where stat() *randomly* (from the application's
and user's perspective) fails when compiled with 32-bit off_t, then I
think such programs are just fundamentally broken now, and need to be
deprecated. Despite the move to compile everythin with
-D_FILE_OFFSET_BITS=64, last time I checked, Debian still has a number
of packages which are compiled without it, and thus which might
experience random breakage on newer filesystems.

In my opinion, the migration path should be something like this:

Stage 1: Change the default for _FILE_OFFSET_BITS to 64 on all
targets, and make 32-bit off_t accessible only by explicitly
requesting -D_FILE_OFFSET_BITS=32. This should help transition all the
stragglers who are just straggling because they don't know better; the
few who have fundamentally buggy code that's incompatible with 64-bit
off_t can use the workaround (-D_FILE_OFFSET_BITS=32) until they get
their acts together.

Stage 2: Remove all 32-bit off_t infrastructure from the headers and
leave the legacy 32-bit off_t symbols around only for use by
already-linked applications. At this point, New symbol versions can be
introduced for all of the functions (open, etc.) so that hacks
remapping them to the nonconforming namespace names (open->open64,
etc.) can be removed; legacy applications can get the legacy behavior
based on the symbol version rather than the symbol name. This will
also resolve the issue that glibc does not allow you to declare some
of these functions yourself without including the associated header.

I would be perfectly happy with stage 1 being made in the next release
cycle and stafe 2 in the following release cycle, but if it would be
more agreeable to wait 2 or more release cycles before stage 2, that's
still much better than living with the current breakage indefinitely.

Opinions?

Rich