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

[Joop van de Wege]

> Hi,
> 
> 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?
You're right about that and the solution is simple. Just change the
following line:
>                         if ($att_param eq 'Content') {
>                                 $att_ds->{$att_param} = $att->Content();
into
            if ($att_param eq 'Content') {
                     $att_ds->{$att_param} = $att->_Value($att_param);

Or just dump the whole if construction since it is of no use anymore.
What happens is that the export is done using the base64 encoded data
and not the binary data together with the header ContentType set to
base64. The import tool is much harder to convince todo something
special thats why I use this patch. The import tool just import the data
encoded together with the correct encoding type and puts it all nicely
into the database. Viewing the tickets this way and clicking on the
download links gives me nicely the binary data on disk ;-)

Jesse, feel free to enhence rt2-to-rt3 with this information.
Personally I would have liked a solution where the export does the right
thing, namely what it does originally since then the exported data then
looks like the original mail with binary data but I can't get the
encoding type right so that the import side does the right thing. Maybe
when I spend much, much more time on it but this just works and I only
need to get my data into RT3.

Joop



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