[Users] See the 'FILES' section of `man claws-mail` for brief descriptions of the files.

[Removed GDPR]

> The simple answer is that the source code is there to be read but I
> realise that it takes time to learn how to do that and how to find the
> information you need.

I am glad you realize that because that would rather be an escape from
answering :)

> When it comes to backup, just backup all of .claws-mail, you can't go
> wrong that way. The extra space it takes is irrelevant in today's
> computers and you won't be risking anything. Claws is a work in
> progress, there are always bugs and things that aren't clear.

It is not just a question of space but rather of order and information
collision. For example I notice the following structure exists:

~/.claws-mail/RSSyl/.../<some feed>/1
~/.claws-mail/RSSyl/.../<some feed>/2
...
~/.claws-mail/RSSyl/.../<some feed>/N

The messages seems to always be 1-N. When I delete (inside CM) certain
RSS messages which I have read and then refresh the feed - new messages
may arrive. So consider a scenario like this:

1. Your refresh an RSS feed
2. For simplicity lets suppose 3 messages arrive only (1, 2, 3)
3. You backup everything
4. On the next day your read messages 1, 2, 3 and delete them
5. Refresh RSS feed
6. This time new 5 messages arrive (1, 2, ... 5)
7. Something happens and you have to restore from backup
8. During the restore messages 1, 2, 3 get overridden with older files

The question is: how will CM handle such logical/sequence conflict?
Obviously it is even more complicated with a non-sequential mix.

Another example:

~/.claws-mail/tmp/claws-crashed

contains only a string "foo". There are also other tmp files in the
same directory. There are also other files which look as temp data but
it is not clear how CM uses them. Also as mentioned in an earlier
message CM seems not to clean up file structure for deleted IMAP
folders.

So considering all that: Why would anyone want to back up
unnecessary or volatile data which can only create conflict upon
restore? That contradicts the very essence of having a backup.

As you see - the answer is not as simple as "backup everything". After
all one of the reasons for which one chooses to use a powerful mail
client as CM is to have communication organized and handled better, not
merely piled up and randomly colliding with itself.

So I still think it is relevant to have more detailed clarifications
re. the file organization.

> Constructive criticism and questions are fine, demanding answers is
> not.

A demand for clarity should not be automatically condemned as a caprice.
It may be an actual and reasonable necessity, just like I explained. In
software projects documentation is often improved due to such demands.
So it should not be easily refuted or marked as anti-netiquette. The
questions are quite valid and on topic.