automatic kbuildsycoca recreate when home dir and/or install dir changes

[Ralf Habacker]

David Faure schrieb:
> On Tuesday 08 April 2008, Ralf Habacker wrote:
>   
>> [1]
>> I understand that this ksycocarc contains the association - I do not 
>> understand why this file is really required - would the same not be 
>> possible by using a directly association by generating a hash code to 
>> generate a part of the ksycoca filename ?
>>     
>
> Yes this would work too. But it would be very opaque to the (power) user -- how do
> I know which ksycoca file to delete if I have some problem somewhere?
> OK for a debug build one can see the ksycoca path in the debug output...
>
>   
>> you mean something like
>>
>> class KSycoca  {
>> ...
>> public:
>>     typedef enum { localDatabase, globalDatabase } DatabaseType;
>>     
> yes (titlecase, though: LocalDatabase, GlobalDatabase)
>
>   
>>    QString absoluteFilePath(DatabaseType type=localDatabase);
>> ....
>> }
>>     
>
>   
>>> The point is that the ksycoca for KDEDIRS=/d/kde/inst/koffice15dir:/d/kde/inst/kde3
>>> is not the same as the ksycoca for KDEDIRS=/d/kde/inst/koffice16dir:/d/kde/inst/kde3
>>> Hence my idea of ksycocarc for mapping from KDEDIRS to which ksycoca to use
>>> (yes, which is equivalent functionally to naming it ksycoca_d_kde_inst_koffice16dir_separator_d_kde_inst_kde3 :)
>>>   
>>>       
>> the clear text form has the advantage that it is obviously for what 
>> those ksycoca is for which - when using a ksycocarc the association 
>> could reverse looked up.
>>     
>
> parse error in the 2nd part of the sentence, but I guess you mean that finding out
> the kdedirs for this ksycoca file requires opening ksycocarc.
>
>   
>> BTW: There are additional places where (at least partial) pathes are 
>> used in user related files for example 
>> .kde\cache-BRAMSCHE\help\de____khelpcenter__faq__about.docbook
>>     
>
> Yes, but KDEDIRS can be much bigger. It just seems dirty.
>
>   
>>  - otherwise see [1]
>>     
>
> 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. One question is if there 
should be a config switch to enable/disable this stuff ?

>   
>> What is left open is what you wrote already - how to delete obsolates 
>> ksycoca files ? The real question is how should it be possible to 
>> estimate if a given ksycoca will not be used in the future again ?
>>     
>
> 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 );
    str << filestamp;
    str << existingResourceDirs();
    if (g_vfolder)
        str << g_vfolder->allDirectories(); // Extra resource dirs

May be a related check could be added to kbuildsycoca.
>   
> But if we only use a hash value in the name then we'll never delete files. 
see above
> However the number of kde installations that a given user has can't be that big that this would be a real problem, I think.
>   
>> As far as i remember there is a timestamp in the ksycoca file - this 
>> could probably be used by kbuildsycoca to detect outdated files, which 
>> could be then deleted.
>>     
>
> ksycoca is only touched when some .desktop file is modified. If an enterprise user (or even a kiosk-like machine)
> runs the same version of KDE for a number of years, and never installs software or changes file associations,
> ksycoca won't change during that time.
> However if we make sure we don't delete the ksycoca for the running kde session (kbuildsycoca's own $KDEDIRS),
> but only -other- ksycoca files, then no problem. Running multiple versions of KDE under one user is already
> rare enough; having them running at the same time for years is even less likely.
>   
I see.


Ralf

-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: ksycoca-different-names.patch
URL: <http://mail.kde.org/pipermail/kde-core-devel/attachments/20080416/5afc73d0/attachment.ksh>