> 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 <[email protected]> > > 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. > > Vishesh Handa wrote: > 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?
We of course check the mtime as we have done for ages. I think KTorrent uses mmapped files for multi-file downloads. Not sure. But that was how I noticed the problem in the first place. Amarok should open files read-only and only open them read/write when changing the metadata. - Sebastian ----------------------------------------------------------- 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 > >
_______________________________________________ Nepomuk mailing list [email protected] https://mail.kde.org/mailman/listinfo/nepomuk
