Arnt Gulbrandsen wrote: >Stephen R. van den Berg wrote: >> Arnt Gulbrandsen wrote: >> >> at some later point in time. Most of the repository is going >> >> to be coherent and accessible soon. Restoring the attachments >> >> (which first) can then be prioritised according to urgency.
>> >Unfortunately, while the database is coherent as far as SQL goes, it's >> >not coherent in the IMAP sense, and fixing that up woud be real work. >> It would mean that imap would return a message with (forced) empty >> attachments, you think that would be difficult to get right? >Either tricky to get right, or hard on the database, or both. I don't >feel good about that when alternatives like this exist: >I know they're slow, but I like these queries _so_ much better than a >200-line block of C++ that modifies the database. Why should we be modifying the database? What I would like to propose and implement is non-destructive on the db, i.e. the db should not and must not be modified depending on the (un)availability of the external bodyparts. There should be at most three settings to the system (possibly configurable per mailfolder/user/globally): a. Do not allow the folder to be opened unless all (external) bodyparts are present and accounted for. b. Do not allow the mail to be opened unless all (external) bodyparts are available. c. Allow the mail to be opened, even if external bodyparts are not available, just include empty files (or placeholder space-garbage, whatever is easier to implement) for the missing external bodyparts. I fail to understand how this could be hard on the database. -- Stephen.
