[EP-tech] Re: Base64 decoding in 3.3

Tim Brody tdb2 at ecs.soton.ac.uk
Tue May 29 15:48:17 BST 2012


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?
> 
Hi,

I can't replicate this. I did find a bug in XMLFiles for *producing*
base64 encoded files, fixed by this:
http://trac.eprints.org/eprints/ticket/4057

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,
Tim
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 490 bytes
Desc: This is a digitally signed message part
Url : http://mailman.ecs.soton.ac.uk/pipermail/eprints-tech/attachments/20120529/cac8b4e9/attachment.bin 


More information about the Eprints-tech mailing list