EPrints Technical Mailing List Archive

Message: #00653

< Previous (by date) | Next (by date) > | < Previous (in thread) | Next (in thread) > | Messages - Most Recent First | Threads - Most Recent First

[EP-tech] Re: Base64 decoding in 3.3

Hi Tim,

I have sent you the files. I have also been able to fix it I changed within File.pm I have changes "sub characters" FROM:

print $tmpfile MIME::Base64::decode_base64( substr($_,0,length($_) - length($_)%77) );


print $tmpfile MIME::Base64::decode_base64( substr($_,0,length($_) - length($_)%4) );

this seem to stop the chunking from breaking up individual byes and causing the problem. I am still testing this but would be great to know what you think.


-----eprints-tech-bounces@ecs.soton.ac.uk wrote: -----
To: eprints-tech@ecs.soton.ac.uk
From: Tim Brody
Sent by: eprints-tech-bounces@ecs.soton.ac.uk
Date: 05/29/2012 03:50PM
Subject: [EP-tech] Re: Base64 decoding in 3.3

On Tue, 2012-05-29 at 12:18 +0100, James Colhoun wrote:
> 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?

I can't replicate this. I did find a bug in XMLFiles for *producing*
base64 encoded files, fixed by this:

This could be an edge case - can you post your XML somewhere or email it
to me directly (if not too big)?

All the best,

[attachment "signature.asc" removed by James Colhoun/sisjc5/CardiffUniversity]