Binary incompatibility issue in JuK saved data

[Michael Pyne]

Hi all,

Although I had done some very minor testing of KDE 4's JuK before the release, 
I had never tested importing the saved data of KDE 3's JuK and seeing what 
happened. (i.e. cp -al $KDE3HOME/share/apps/juk $KDE4HOME/share/apps).

Unfortunately what happens is the JuK is unable to read in the binary encoded 
saved playlists and cache.

The cache is not a big deal; it can be deleted and then regenerated.  
Playlists stored in .m3u won't be affected as they are stored in the 
standard .m3u format.

The problem is the file $KDEHOME/share/apps/juk/playlists, which contains 
basically the entire music collection and list of playlists you've created.  
The issue is that JuK never specified the binary version to use with the 
QDataStreams when saving or loading that file.  Normally this isn't an issue.  
The QDataStream was binary compatible (or close enough for JuK's usage) 
during pretty much all of KDE 3.3 - 3.5 (which all used Qt 3.3 IIRC).  I 
never thought about it otherwise because I somehow had the idea that a 
QDataStream would encode it's binary version in the output stream and 
automatically set itself appropriately while reading it back in.  But I guess 
it doesn't, and I haven't seen anything in the class documentation to suggest 
that it would.

Now, I can fix the issue and allow JuK to read in KDE 3 information again.  
But this would break the files saved with JuK from 4.0.0 (they were saved 
with the same playlist version number as KDE 3.5 but are binary incompatble 
due to different Qt libraries; i.e. there is no way to tell while reading 
which you have, KDE 3 or 4's.)

If I don't fix it people can't easily migrate their JuK collection over 
without re-adding everything.

One thing that's been suggested is to simply guess which one if a KDE 3.5 
version is encoded and then if it doesn't work then to read assuming KDE 4.  
But JuK will load fine with a 3.5 playlists file (until you click on a 
playlist and it crashes).  I suppose I could add more sanity-checking while 
loading but I'm not sure how feasible it is to catch all the cases where a 
KDE 3.5 playlists would affect JuK.

To cut a long story short however, unless anyone has a better idea my 
intention is to:

* Bump the JuK version encoded in the playlists file and enforce a specific 
QDataStream version.
* Read in the files encoded with the KDE 3.5/4.0.0 version as if they were 
saved by Qt 3.3, and add sanity checking checks to force trying to load using 
Qt 4 if that doesn't work.  I can't guarantee that this will reliably allow 
JuK in KDE 4.1 or 4.0.1 to load files from 4.0.0 but I think it will at least 
work in most cases.

I can have the patch developed tomorrow (it's basically just adding 
QDataStream::setVersion() calls and bumping the version JuK saves the file 
under) but I just want to get the problem out there so people know.

I would recommend that other programs using QDataStream be looked at as well 
(although I wouldn't be surprised if I were the only one surprised by this).

Regards,
 - Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080107/f4e709b9/attachment.sig>