Re: fsfs migration failure. File too large??

On Tue, May 31, 2005 at 09:45:59PM -0700, Garrett Rooney wrote:
> Why not just compile a version of APR that has the problem fixed by
> making apr_off_t larger (APR 1.x has the fix, Subversion uses APR 0.9.x,
> for binary compat reasons, not because 1.x won't work or something).

 I don't think this addresses the problem that this user was seeing
though - it addresses a distinct but related one. Trying to stuff a 64
bit off_t into the int provided by APR just ends up with an overflowed
int, wrapped around into the negatives. I think negative offsets are
legal to lseek when used in conjunction with, say, SEEK_CUR. It doesn't
raise SIGXFSZ, that's for sure.

 I think _that_ problem is addressed by making APR open all it's files
with O_LARGEFILE. Of course, just tacking APR_LARGEFILE everywhere
won't help unless O_LARGEFILE was defined in APR at compile time - it
uses this as the gate condition for including the flag, not
_LARGEFILE_SOURCE as you might expect.

 Sekrit Research (TM) has revealed this to be finally dependent ( on Linux
at least ) on stuff defined in /usr/include/features.h, namely
_LARGEFILE_SOURCE and _LARGEFILE64_SOURCE. This is what I suspect
I was doing wrong when I tried to patch SVN on my friends machine
last night. I am puzzled as to why getconf LFS_CFLAGS doesn't
include this deadly duo.

 So yeah. Build APR with those two defines, use APR_LARGEFILE in the
application, and either backport 64 bit file offsets, or use APR 1.x.
And then it _should_ all work. I think.

 B.

-- 
"There were too many of us. We had access to too many, uh, too much money.
 Too much equipment... and little by little we went insane."
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org