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

Re: Bug with SVN::Client::diff() and in-memory files

From: Malcolm Rowe <malcolm-svn-dev_at_farside.org.uk>
Date: 2006-11-08 15:52:49 CET

On Wed, Nov 08, 2006 at 09:05:28AM -0500, Garrett Rooney wrote:
> On 11/8/06, Nik Clayton <nik@ngo.org.uk> wrote:
> >SVN::Client::diff() is supposed to take (as part of its interface) two file
> >handles, where the output and errors will be sent, respectively.
> >
> >If these are two file handles that correspond to files on disk then
> >everything works as expected.
> >
>
> This is not all that surprising. The diff functions don't take
> streams, they work in terms of apr_file_t, so they really do expect
> there to be an actual file on disk. The fix is to rewrite them to
> work in terms of streams (not trivial, IIRC), or work around it in
> either the bindings or in your application by writing that in-memory
> data to disk and passing in handles to those files to diff.
>

I doubt that the diff code really needs the file to exist on disk,
though it probably does need it to be a seekable filehandle.

The code that converts a Perl file glob to an apr_file_t* is in
svn_swig_pl_make_file(), and just grabs the OS filehandle from the Perl
glob and apr_os_file_put()'s it into a new apr_file_t structure, with
roughly ('file' is the Perl reference-to-glob):

        apr_os_file_t osfile = PerlIO_fileno(IoIFP(sv_2io(file)));
        status = apr_os_file_put(&apr_file, &osfile,
                                 O_CREAT | O_WRONLY, pool);

It's possible that Perl's in-memory files don't have a filehandle, and
so osfile is being set to a bogus value. If so, we should probably flag
an early error at this point rather than waiting for the write to fail
later. (Or, if we can get an OS filehandle for the glob using some
other mechanism, do that).

Regards,
Malcolm

  • application/pgp-signature attachment: stored
Received on Wed Nov 8 15:53:57 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.