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