Binary incompatibility issue in JuK saved data
mpyne at purinchu.net
Tue Jan 8 04:30:40 GMT 2008
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
* 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).
- Michael Pyne
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 189 bytes
Desc: This is a digitally signed message part.
More information about the kde-core-devel