search for: mailbx

...Is the Dovecot core sending again all the emails to index ? or the fts shall somehow access the mailbox and read all emails ? Wouldn't just be saying "delete all index and get_last_uid is now 0" the easy way ? or the fts must process all emails (and block the current thread as a mailbx maybe quite large) 3 - for get_last_uid : this uncertainity is very unclear. "If there is a gap, then indexer first indexes all the missing" -> this mean at a certain point, indexer maybe rebuilding a previous email, so *last* uid is something different than max. And how indexer d...

...lbox and read all emails ? Wouldn't just be </div> <div> saying "delete all index and get_last_uid is now 0" the easy way ? or </div> <div> the fts must process all emails (and block the current thread as a </div> <div> mailbx maybe quite large) </div> <div> <br> </div> <div> 3 - for get_last_uid : this uncertainity is very unclear. "If there is a </div> <div> <br> </div> <div> gap, then indexer first indexes all the...

...ain all the emails to index ? or the fts >> shall somehow access the mailbox and read all emails ? Wouldn't just be >> saying "delete all index and get_last_uid is now 0" the easy way ? or >> the fts must process all emails (and block the current thread as a >> mailbx maybe quite large) > > The next indexing run is responsible for it. If you return get_last_uid=0, then indexer starts feeding you all mails. So fts backend doesn't have to know about it. > >> 3 - for get_last_uid : this uncertainity is very unclear. "If there is a >>...

...core sending again all the emails to index ? or the fts > shall somehow access the mailbox and read all emails ? Wouldn't just be > saying "delete all index and get_last_uid is now 0" the easy way ? or > the fts must process all emails (and block the current thread as a > mailbx maybe quite large) > The next indexing run is responsible for it. If you return get_last_uid=0, then indexer starts feeding you all mails. So fts backend doesn't have to know about it. > > 3 - for get_last_uid : this uncertainity is very unclear. "If there is a > gap, then in...

...Is the Dovecot core sending again all the emails to index ? or the fts shall somehow access the mailbox and read all emails ? Wouldn't just be saying "delete all index and get_last_uid is now 0" the easy way ? or the fts must process all emails (and block the current thread as a mailbx maybe quite large) 3 - for get_last_uid : this uncertainity is very unclear. "If there is a gap, then indexer first indexes all the missing" -> this mean at a certain point, indexer maybe rebuilding a previous email, so *last* uid is something different than max. And how indexer d...

...core sending again all the emails to index ? or the fts > shall somehow access the mailbox and read all emails ? Wouldn't just be > saying "delete all index and get_last_uid is now 0" the easy way ? or > the fts must process all emails (and block the current thread as a > mailbx maybe quite large) The next indexing run is responsible for it. If you return get_last_uid=0, then indexer starts feeding you all mails. So fts backend doesn't have to know about it. > 3 - for get_last_uid : this uncertainity is very unclear. "If there is a > gap, then indexer firs...

...all the emails to index ? or the fts >> shall somehow access the mailbox and read all emails ? Wouldn't just be >> saying "delete all index and get_last_uid is now 0" the easy way ? or >> the fts must process all emails (and block the current thread as a >> mailbx maybe quite large) >> >> 3 - for get_last_uid : this uncertainity is very unclear. "If there is a >> >> gap, then indexer first indexes all the missing" -> this mean at a >> certain point, indexer maybe rebuilding a previous email, so *last* uid >...

...lbox and read all emails ? Wouldn't just be </div> <div> saying "delete all index and get_last_uid is now 0" the easy way ? or </div> <div> the fts must process all emails (and block the current thread as a </div> <div> mailbx maybe quite large) </div> <div> <br> </div> <div> 3 - for get_last_uid : this uncertainity is very unclear. "If there is a </div> <div> gap, then indexer first indexes all the missing" -> this mean at a </div...

...core sending again all the emails to index ? or the fts > shall somehow access the mailbox and read all emails ? Wouldn't just be > saying "delete all index and get_last_uid is now 0" the easy way ? or > the fts must process all emails (and block the current thread as a > mailbx maybe quite large) > The next indexing run is responsible for it. If you return get_last_uid=0, then indexer starts feeding you all mails. So fts backend doesn't have to know about it. > > 3 - for get_last_uid : this uncertainity is very unclear. "If there is a > gap, then in...

...ail ? Is the Dovecot core sending again all the emails to index ? or the fts shall somehow access the mailbox and read all emails ? Wouldn't just be saying "delete all index and get_last_uid is now 0" the easy way ? or the fts must process all emails (and block the current thread as a mailbx maybe quite large) > > - for get_last_uid : this uncertainity is very unclear. "If there is a gap, then indexer first indexes all the missing" -> this mean at a certain point, indexer maybe rebuilding a previous email, so *last* uid is something different than max. And how inde...

...core sending again all the emails to index ? or the fts > shall somehow access the mailbox and read all emails ? Wouldn't just be > saying "delete all index and get_last_uid is now 0" the easy way ? or > the fts must process all emails (and block the current thread as a > mailbx maybe quite large) > The next indexing run is responsible for it. If you return get_last_uid=0, then indexer starts feeding you all mails. So fts backend doesn't have to know about it. > > 3 - for get_last_uid : this uncertainity is very unclear. "If there is a > gap, then in...

...ail ? Is the Dovecot core sending again all the emails to index ? or the fts shall somehow access the mailbox and read all emails ? Wouldn't just be saying "delete all index and get_last_uid is now 0" the easy way ? or the fts must process all emails (and block the current thread as a mailbx maybe quite large) - for get_last_uid : this uncertainity is very unclear. "If there is a gap, then indexer first indexes all the missing" -> this mean at a certain point, indexer maybe rebuilding a previous email, so *last* uid is something different than max. And how indexer does k...

...ail ? Is the Dovecot core sending again all the emails to index ? or the fts shall somehow access the mailbox and read all emails ? Wouldn't just be saying "delete all index and get_last_uid is now 0" the easy way ? or the fts must process all emails (and block the current thread as a mailbx maybe quite large) 3 - for get_last_uid : this uncertainity is very unclear. "If there is a gap, then indexer first indexes all the missing" -> this mean at a certain point, indexer maybe rebuilding a previous email, so *last* uid is something different than max. And how indexer does...

...all the emails to index ? or the fts >> shall somehow access the mailbox and read all emails ? Wouldn't just be >> saying "delete all index and get_last_uid is now 0" the easy way ? or >> the fts must process all emails (and block the current thread as a >> mailbx maybe quite large) >> >> 3 - for get_last_uid : this uncertainity is very unclear. "If there is a >> gap, then indexer first indexes all the missing" -> this mean at a >> certain point, indexer maybe rebuilding a previous email, so *last* uid >> is so...

On 7 Jan 2019, at 16.05, Joan Moreau via dovecot <dovecot at dovecot.org> wrote: > > Hi > > ANyone to answer specifically ? > > Q1 : get_last_uid -> Is this the last UID indexed (which may be not the greatest value), or the gratest value (which may not be the latest) (the code of existing plugins is unclear about this, Solr looks for the greatest for insance) All the