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

[Brian Morrison]

On Thu, 8 Mar 2018 15:07:32 +0200
Removed GDPR wrote:

> > 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 :)

Well you need to realise that nothing comes for nothing, if you want
knowledge you need to invest time and effort.

> 
> > 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?

It won't. Everything will be fucked up. You are asking for a database,
Claws doesn't have one. RSS feeds are viewed as volatile and
non-protected.

> 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.

Temp folders are never intended to be permanent, if it says "temp" or
"tmp" then ignore that folder. If you restore from a backup then do
that in a new directory and sanitise it before you copy it over your
real .claws-mail, always have copies of the current file tree in case
you make a mistake.

> 
> 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.

Free Software is not expected to be perfect, when there is something
wrong that bugs you then it is reasonable to expect you to fix it
either by submitting code or by offering improved documentation. If it
breaks, you get to keep all the pieces.

> 
> > 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.

I've tried to be helpful and have replied to you several times with
assistance and suggestions. I don't have to, no one pays me to be here
or read anything anyone writes. I don't want to be rude but as you can
see some people have already been provoked into telling you you're
being too demanding. I think you need to consider what you can
reasonably expect, especially because you are clearly very demanding of
your email experience and in terms of security and privacy. None of
those things are easy or come for nothing.

HTH

-- 

Brian Morrison