[EP-tech] Base64 decoding in 3.3

James Colhoun ColhounJ at cardiff.ac.uk
Tue May 29 12:18:55 BST 2012


Hi,

I am uploading publications via sword, full text files are added to the upload xml and encoded in base64 this worked fine until we upgraded to 3.3. Now we get errors in the log:

 failed: expected 3151 bytes but actually got 3149 bytes

So it seems the decoding of base64 is no longer working correctly. Inside EPrints/DataObj/File.pm the functions: end_element, characters and start_element seems to create a tmp file that is corrupt.  If I add a write to file inside "sub characters" (see below) the pdf is created correctly so I know the data is passed in correctly, there seems to be something fundamentally broken with the way the decoding to tmpfile is working. Has anyone seen this are have a fix for it?


 if( $state->{depth} == 2 && defined $state->{encoding} )
       {
               my $tmpfile = $epdata->{_content};
               $state->{buffer} .= $data->{Data};

open (MYFILE, '>>/tmp/data2.pdf');
print MYFILE  MIME::Base64::decode_base64($data->{Data});
close (MYFILE);


                for($state->{buffer})
                {
                        #print $tmpfile MIME::Base64::decode_base64( substr($_,0,length($_) - length($_)%77) );
                        $_ = substr($_,length($_) - length($_)%77);
                }
        }


-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20120529/38c483f9/attachment.html 


More information about the Eprints-tech mailing list