Changes between Initial Version and Version 2 of Ticket #133


Ignore:
Timestamp:
Dec 18, 2010 2:16:01 PM (4 years ago)
Author:
tboeckel
Comment:

Having read this ticket now by a hundred times I really wonder how that could be accomplished. The task is easy: rename the existing index file before creating a new one. If loading an index file is not possible fall back to the backed up one.

The big issue I see here is the consistency of the backed up data. How can we make sure the backed up index really still represents the current state?

Imagine the following: the current index is backed up, because some mails were deleted from a folder. Before YAM is able to save the new index the machine crashes or is switched off or etc, but the deleted mails don't exist any more. The next time YAM is started it will use the backed up index because the normal index doesn't exist. But the backed up index still contains the formerly deleted mails, although the respective files don't exist anymore and accessing these "phantom" mails will generate further errors.

In this situation only a complete rescan will yield the correct information about the still existing mail files. And this is exactly what we already have right now. Or do I miss something here?

One solution would be to make sure that the most recent backed up index file really represents the current state. But that would require to save the index after each modification. And for folders with lots of mails this must be considered a very expensive approach in terms of CPU load and unresponsiveness of the application. Furthermore this approach would make a backed up index absolutely useless as there is nothing to backup.

Even the proposed checksum does not help very much from my point of view. To be able to compare the saved checksum against a checksum of the current state again requires all mails to be scanned to generate the checksum. So where is the advantage here? Ok, the checksum could be a solution if only such information is taken into account which can be obtained without having to deeply scan each file, i.e. compute the CRC just from the file's name and size which can be obtained quite fast with a simple directory scan.

Ideas are welcome!

Legend:

Unmodified
Added
Removed
Modified
  • Ticket #133

    • Property Status changed from new to accepted

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

These roles will be notified: Reporter, Owner, Subscriber

  • Jens Maus(Reporter, Participant)