Comments you submit will be routed for moderation. If you have an account, please log in first.

Opened 6 years ago

Closed 5 years ago

#54 closed enhancement (wontfix)

No-indexing startup option

Reported by: ojciec_swiety@… Owned by:
Priority: low Milestone: YAM 2.7
Component: mail indexing Version:
Severity: minor Keywords:
Cc: OS Platform:
Blocked By: Blocking:
Release Notes:

Description (last modified by tboeckel)

Would be possible to add a startup option to skip folder re-indexing? I've just searched for an older email in one of my backup CDs. So I run YAM with maildir option pointing to that CD. Unfortunately, YAM insisted on updating the indexes which is rather hopeless on read-only media. It tried to write to disc on each single mail so canceling zillions of requesters was not an option. Finally I decided to copy whole YAM dir to t: and redirect YAM there. It worked but reindexing took really long (tons of emails). That's why my suggestion to add an option for skipping indexing procedure - it would enable fast access to folders created by older versions of YAM.

Moved from SF:

Attachments (0)

Change History (5)

comment:1 Changed 6 years ago by damato

  • Component changed from stable build to undefined

comment:2 Changed 6 years ago by damato

  • Cc yamos-svn@… removed

comment:3 Changed 6 years ago by damato

  • Component changed from undefined to mail indexing
  • Milestone set to YAM 2.7
  • Priority changed from undecided to low
  • Severity changed from major to minor
  • Status changed from new to accepted

This sounds reasonable and actually doable. We could also probably add a possibility that YAM may interactively ask the user if he wants the indexing done right away or later. However, the question remains what happens if the inbox or any other mandatory folder needs indexing, what should happen then?

comment:4 Changed 5 years ago by tboeckel

  • Description modified (diff)
  • Status changed from accepted to pending

I think the most important point is to check here is why YAM is trying to recreate the index at all. Is it just because the dates of the folder and the .findex file were altered and thus YAM thinks the index is outdated/corrupted or is there a another reason? Or is it because the backed up index on the CD has an older version than YAM currently uses?

Second, how should YAM react in case a mail's state has to be changed (i.e. from "new/unread" to "read"? This requires write access to the disk or you will get tons of further "disk is write protected" requesters and the next time you start YAM the mails will have their old state. Although this must be acceptable.

One solution would be to either accept index files from read-only media as they are and never perform a rescan, but this would mean old mail backups cannot be used with future versions of YAM and a changed index file layout.

Doing the rescan once is no 100% solution either, as YAM will automatically flush unused indices from memory and reload them when necessary, but this would result in yet another rescan. In this case the index must be marked as "not flushable" to avoid the constant rescan. But this all only holds true as long as YAM is not restarted. After a restart the scan will be due again.

From my point of view it all comes down to one question: why is the index rebuilding necessary at all and can any logic inside YAM make this necessity more tolerable? The way YAM handles its mails simply requires a disk that can be written to.


comment:5 Changed 5 years ago by tboeckel

  • Resolution set to wontfix
  • Status changed from pending to closed

Closing this ticket as I really don't know how to fix it. If the index file is deleted because it is outdated keeping a backup of it makes no sense, since the backed up file is still outdated and cannot be used.

Add Comment

Modify Ticket

as closed The ticket will remain with no owner.
The resolution will be deleted. Next status will be 'reopened'.

E-mail address and user name can be saved in the Preferences.

Note: See TracTickets for help on using tickets.

This list contains all users that will be notified about changes made to this ticket.

These roles will be notified: Reporter, Owner, Subscriber

  • ojciec_swiety@…(Reporter)