automatic kbuildsycoca recreate when home dir and/or install dir changes
David Faure
faure at kde.org
Thu Apr 17 13:05:58 BST 2008
On Wednesday 16 April 2008, Ralf Habacker wrote:
> > Let's try with a hash value for now, it's the solution that requires the least amount of code.
> > We can always change this later on if we don't like it - that's the good thing about ksycoca,
> > it's just a cache, so we can always delete it or "forget an old one and use a new filename in the future".
> >
> appended is a related patch for reviewing.
Thanks. Looks good to me; I would just
* add a comment in the code about why we do this
* deprecate/remove the KSYCOCA_FILENAME macro in ksycoca.h -- it was there for kbuildsycoca.h
but nowadays it's encapsulated by absoluteFilePath() so it has no reason to stay there other
than theoretical source compat (but a useless one since it's not the name of the file anymore).
lxr confirms that nothing in kde uses it. I would just remove it, nothing should use it.
> One question is if there should be a config switch to enable/disable this stuff ?
I can't see a good reason for this, actually.
> > As I said, if the KDEDIRS associated with it don't exist anymore, then it's safe to delete it.
> >
> we would be able to get the associated KDEDIR from inside the ksycoca
> database or from the related stampfile if it would be extended to hold
> the kdedirs values beside the timestamp, the existingResourceDir and the
> folder dirs too.
>
> from kbuildsycoca
>
> QString path = sycocaPath()+"stamp";
> QFile ksycocastamp(stamppath);
> ksycocastamp.open( QIODevice::WriteOnly );
> QDataStream str( &ksycocastamp );
Hmm, we should use QDataStream::setVersion() here, to ensure that all timestamp
files are compatible; otherwise we can't implement your "open the file and check
if it needs to be deleted" idea later on without a crash risk.
> May be a related check could be added to kbuildsycoca.
Opening all stamp files and deleting the "dead" sycocas? OK...
--
David Faure, faure at kde.org, sponsored by Trolltech to work on KDE,
Konqueror (http://www.konqueror.org), and KOffice (http://www.koffice.org).
More information about the kde-core-devel
mailing list