[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: tmpfile callback problems.

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-09-19 00:39:42 CEST

Ben and I talked about this over AIM (gstein67, if you wonder). We resolved
the obvious issues, but it appears something a little more ugly is still
happening in there. Ben is going to debug some more tomorrow.

On Tue, Sep 18, 2001 at 10:25:16PM +0100, Joe Orton wrote:
> On Tue, Sep 18, 2001 at 04:08:33PM -0500, Ben Collins-Sussman wrote:
> ...
> > So now I discover ickiness... apparently in both the commit and update
> > cases, ra_dav needs to hand a vanilla "FILE *" version of the tmpfile
> > to neon; an apr_file_t won't do. So ra_dav closes the apr_file_t,
> > then fopen()/fclose()'s the file for neon.
>
> neon actually takes an integer fd in 0.15, so the FILE * is
> historical... but this doesn't help you.

We figured that one out after a bit :-)

> An apr_file_t can't be
> (portably) morphed into anything useful to neon AFAIK.

Actually, you can... look at the (misnamed) apr_portable.h header file.
There is a way to get the file descriptor out of the apr_file_t.

However, I suspect that will return the HANDLE on Windows, which will be
wrong for Neon. Need to look a bit more.

Time for that use-APR-in-Neon patch :-)

>...
> > Still though -- I get a segfault when committing, specifically in
> > commit_stream_close, because fopen() tries to reopen the tmpfile, and
> > it's already gone somehow.
>
> Yeah, I think that's how it works... because it's been unlink()ed by APR
> to implement DELONCLOSE, it no longer has a name in the filesystem. So
> you can't open it again. :(

Yup.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:41 2006

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.