[rt-users] dumpfile-to-rt-3.0 problem: parser: unterminated quotedstring

[Joop van de Wege]

> I've detected the reason of the problem, but I don't know how to
woraroud
> it.
> The cause is that the attachment is marked as base64-encoded while IT IS
> NOT!
> It was base64-encoded in the RT2 database, I checked that up with direct SQL
> query.
> But serialized version of the ticket in the exported form contains decoded
> content of the attachment.
> I can't find decoding in rt-2.0-to-dumpfile script so it must be performed
> somewhere in the RT library (probably $att->Content() do that???). So
> dumpfile-to-rt-3.0 have to encode it back to base64 to be able to store it
> to the database.
> 
> In this case the problem must be in this piece of code of the
> rt-2.0-to-dumpfile script:
> 
>                   my $att_param ( sort keys %{ $att->{_AccessibleCache} } )
> {
>                         if ($att_param eq 'Content') {
>                                 $att_ds->{$att_param} = $att->Content();
> 
>                          } else {
> 
>                                 $att_ds->{$att_param} =
> $att->_Value($att_param)
>                                         if (defined $att->_Value($att_param)
> );
>                          }
> 
> and actualy there is no need to decode attachment content if it is
> base64-encoded?
> 
> Regards,
> -- 
> Alexei Barantsev
I'm having a similar problem moving data from RT2.0.13 to RT3.2.0 using
Oracle as a backend.
The same problem, data in RT2 is base64 encoded in the database, which
is regulated through the BinarySafeBlobs boolean in SearchBuilder. If
set to true it will store binaries in binary else it will base64 encode
them and store them in ASCII. 
If you read through Attachment.pm in lib/RT there it will say that it
will decode base64 before returning it to the client app in this case
rt2-to-dumpfile which will store it decoded into the dumpfiles. There it
will also store that it is base64 encoded data which is not correct.
Further when this data is imported using dumpfile-to-rt3 I think
something else goes wrong
- it should honor either the fact that the encoding is no longer base64
thus ignoring the explicit encoding-type.
- or maybe it shouldn't use Import but Create in which case it may
correctly figure out that it is binary and needs to be encoded.

Looking at some code it looks like there is something that might be
usable to both of us namely: RT::AlwaysUseBase64.
I'm going to investigate tomorrow if either BLOB's in Oracle work or if
I can force base64 encoding which it already should do according to
SearchBuilder/Handle/Oracle.pm

Joop
PS:
Sorry for any mistake in logic, its getting late after quite a few
looongg days.

-- 
Joop van de Wege <JoopvandeWege at mococo.nl>