Re: fsfs migration failure. File too large??

 Hi Everyone.

 The thread about Tess' problems with FSFS migration was brought to my
attention, and I exchanged a few mails with Ben on what I thought the
problem might be. As I seem to be committed to seeing this through to
it's gory conclusion, I've signed on to the list and will repost
what we discussed here, in case anyone else can throw in their two cents.
I'm a bit of a newbie, so feel free to rip it to bits.

 This is the condensed version. ;-)

 APR_LARGEFILE - flag for apr_file_open

 The older builds of SVN don't seem to use this flag, which was added to APR's
apr_file_open by Joe Orton back in 0.9.4-??. The latest cut I'm aware of
( 1.2.0 ) uses it for copy_db_file_safely, but nowhere else, as far as I'm
aware. Ben has brought this up on the dev@ list, and it was pointed out
by another poster that slathering APR_LARGEFILE on liberally is not a panacea
for these problems, as the older 0.9.6 APR's define the type apr_seek_where_t
as an int... to follow POSIX, I guess. Unfortunately, I think off_t has been
a minimum of 64 bits wide since unix98.

 If SVN was amended to use APR_LARGEFILE, we'd be able to open, read and
write large files, but not seek around inside them. I'm told this is a
dealbreaker for fsfs.

 The solution I envision as involving the minimal amount of bloodshed right
now would be to take the distribution of apr included with subversion, change
it to use off_t for apr_seek_where_t where it's available, print warnings
where it isn't, and force the use of O_LARGEFILE to open, where it's defined.
( This last bit runs against the LFS coding specifications, but at this point,
who cares. It's the legacy tree anyway. ) People would have to build SVN
against this copy of apr.

 I am happy to attempt to try and write the patch tonight, but the big
question is, do people think it will cover all the problems? Will it work?
Etc??

 One last troubling thing is that I shot over to a friends linux box to have
a fiddle with this stuff, and found out that fnctl.h wasn't defining
O_LARGEFILE on his system, even though manually inserting the bitmask into
the flags for open(2) worked fine. Digging in include/bits/fnctl.h
shows that it's only defined if __USE_LARGEFILE64 is defined in turn. We
don't have the concept of O_LARGEFILE on darwin, so I'm a bit uncertain
about all this. Would it be prudent to define the flag ourselves? Can
a linux guru advise me on this?

 Let me know what you think,
  Bryn.

-- 
"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