This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 0/2] Squashing long inodes.
- From: Rich Felker <dalias at aerifal dot cx>
- To: Paul Eggert <eggert at cs dot ucla dot edu>
- Cc: Denis Obrezkov <reprofy at etersoft dot ru>, libc-alpha at sourceware dot org
- Date: Fri, 28 Feb 2014 19:22:52 -0500
- Subject: Re: [PATCH 0/2] Squashing long inodes.
- Authentication-results: sourceware.org; auth=none
- References: <1393521776-1102-1-git-send-email-reprofy at etersoft dot ru> <530F79C1 dot 2040508 at cs dot ucla dot edu>
On Thu, Feb 27, 2014 at 09:45:37AM -0800, Paul Eggert wrote:
> Squashing an inode that way has a small chance of introducing what
> could be a serious bug. If glibc is going to squash them, it should
> do so reliably, by maintaining a table of all the inodes it's ever
> seen and making sure there are no collisions.
>
> Why bother to squash them at all, though? Programs that care about
> files should be compiled with _FILE_OFFSET_BITS defined to 64. If
> we're worried about programs that don't define _FILE_OFFSET_BITS, we
> could change glibc to default to _FILE_OFFSET_BITS=64; that's a
> better long-term solution anyway.
I am strongly in favor of fixing this default. There are still a
nontrivial number of Debian packages, including some libraries that
could be used in arbitrary programs, compiled without
-D_FILE_OFFSET_BITS=64. Serious bugs can occur (including corruption
of large files) when you mix code that works with and without
O_LARGEFILE; this can happen even if the mixing is across separate
processes/executables, due to file descriptor inheritance across
fork/exec; the most common example is where a program with 32-bit
off_t receives a large-mode file descriptor as stdin or stdout. The
old non-64-bit interfaces really just need to be deprecated, and
making them nondefault (so you can't get them without explicitly using
-D_FILE_OFFSET_BITS=32) is the first step in making their deprecation
go smoothly.
Rich