[Nepomuk] Review Request: Do not reindex files on only WriteOnClose Events

[Vishesh Handa]

> On Jan. 26, 2012, 7:32 p.m., Sebastian Trueg wrote:
> > Thanks to quickgit not doing what it should here is a copy of the commit message which explains why your review request sadly needs to go to the bin:
> > 
> > commit 25ce125c5bf43fe0a44ca5797a8234ad4398d6b8
> > Author: Sebastian Trueg <trueg at kde.org>
> > Date:   Tue Oct 18 11:41:13 2011 +0200
> > 
> >     Always re-index files on close after write events.
> >     
> >     This is required since mmapped files do not create modification events
> >     while being written.
> 
> Vishesh Handa wrote:
>     So, that's an inotify bug. It should be fixed over there.
>     
>     I don't see why we should have unnecessary re-indexing cause of that. It's extremely irritating if I'm seeding a lot of files.
> 
> Sebastian Trueg wrote:
>     Whether the bug is in inotify or somewhere else does not matter. The fact is that ktorrent uses mmapped files. Thus, already for that use case we need to stick to the current solution. Also nothing should be re-indexed as nothing changed. The only thing that would happen is that the file indexer checks if it needs to re-index the file. Also there is some compression of those close write events. If its not enough we can raise the timeout.

What about Amarok? Why should the files be reindexed when the track on the playlist changes?

It will be reindexed as the CloseOnWrite tells the file indexer to index it. The option is to obviously check the sha1sum of the file before indexing it, but that's a lot of effort .. or we could check the modification date, since that shouldn't have changed. What do you think?

And btw, what does ktorrent use memory mapped files for?


- Vishesh


-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
http://git.reviewboard.kde.org/r/103794/#review10102
-----------------------------------------------------------


On Jan. 26, 2012, 12:41 p.m., Vishesh Handa wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> http://git.reviewboard.kde.org/r/103794/
> -----------------------------------------------------------
> 
> (Updated Jan. 26, 2012, 12:41 p.m.)
> 
> 
> Review request for Nepomuk, Alex Fiestas and Sebastian Trueg.
> 
> 
> Description
> -------
> 
> This Filewatcher sends files for reindexing when it receives a WriteOnClose event from inotify. This event is generated whenever a file opened in write mode is closed. Even if they were no changes.
> 
> Programs like Amarok and KTorrent often open the files in write mode even when they don't make any changes. Which results in reindexing of those files.
> 
> For a graphical example - http://www.afiestas.org/nepomukReindexing.ogv
> 
> 
> Diffs
> -----
> 
>   nepomuk/services/filewatch/activefilequeue.h 19d4813 
>   nepomuk/services/filewatch/activefilequeue.cpp 8bb54ed 
>   nepomuk/services/filewatch/nepomukfilewatch.h cfb02fc 
>   nepomuk/services/filewatch/nepomukfilewatch.cpp 60550c2 
>   nepomuk/services/filewatch/test/activefilequeuetest.cpp 0445e8f 
> 
> Diff: http://git.reviewboard.kde.org/r/103794/diff/diff
> 
> 
> Testing
> -------
> 
> All the tests pass, and files are no longer reindexed when the song changes in Amarok.
> 
> 
> Thanks,
> 
> Vishesh Handa
> 
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/nepomuk/attachments/20120126/a24c1613/attachment-0001.html>