Re: [Evolution] Evolution forces conversion from mbox to maildir



On Thu, 2019-12-12 at 11:36 +0100, mwrsa web de wrote:
Is it really the best and safest way to determine the mail storage
format by the presence of an empty folder (and maybe the presence of
the corresponding meta file)?

        Hi,
generally speaking: no. On the other hand, please, remember, you are
touching internal application files/data. That can lead to misbehavior,
just as it happened in your case here. Applications (can) have their
own requirements on their own data.

This part looks to me like a little programming shortcut, not to name
it q&d programming (no insult intended).

No problem. I can understand why it's done so. The Outbox folder is a
mandatory folder and once it is converted all others should be
converted as well. Evolution (or better libcamel) won't let you delete
that folder, neither it deletes it on its own, thus it should be always
there. That's not that bad idea to depend on it, from my point of view.

By the way, the Maildir format means to have three subdirectories on
the disk: 'cur', 'new', 'tmp'. The 'new' and 'tmp' might be mostly
empty, especially for the On This Computer account. That means that
your FSLint constantly breaks the Maildir structure. I'd suggest you to
configure the FSLint to skip ~/.config/ and ~/.local/ at least (some
applications store their private data to other dot-directories). That
way you can restore from backup into exactly the same state, instead
into the state "after running FSLint", which may or may not be the last
running state.

I know these all things are about work flow, habits and so on. I'm
definitely not forcing you to change your habits. I'm only trying to
suggest something to avoid the problem in the future.

Do you have a clue why simply recreating the Outbox
folder did not work, and neither worked copying the folder and its
meta file out of the backup?

No, I'm sorry, I've no idea. Trying to guess would be really just a
guess, which would only confuse things. Either there could be a clue on
the console of the 'evolution' process, like an error message of some
failure, or a deep debugging of the process execution would show why it
did what it did (involving running evolution under gdb, setting
breakpoints and so on).
        Bye,
        Milan



[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]