Bug 3992 - folderitemrc keeps stale data for deleted/renamed folders/accounts
Summary: folderitemrc keeps stale data for deleted/renamed folders/accounts
Status: RESOLVED DUPLICATE of bug 3952
Alias: None
Product: Claws Mail (GTK 2)
Classification: Unclassified
Component: Folders (show other bugs)
Version: 3.16.0
Hardware: PC Linux
: P3 normal
Assignee: users
URL:
Depends on:
Blocks:
 
Reported: 2018-03-19 22:42 UTC by George
Modified: 2018-04-04 08:01 UTC (History)
0 users

See Also:


Attachments

Description George 2018-03-19 22:42:27 UTC
STR:

1. Rename an IMAP account or reorganize/rename folders

EXPECTED:
~/.claws-mail/folderitemrc should update accordingly, removing entries for non-existing items

ACTUAL:
It piles up new data keeping the old.
Comment 1 codejodler 2018-03-20 01:16:48 UTC
I looked up my own claws (Debian Linux, all updated to 'testing' = Sid) and found my folderitemrc is nearly 2 Mb, with entries dating back to at least 2003.

I create / rename / delete again folders very often, with every new project, and also use arbitrary mail IDs, both of which can be confidental. When i deleted this stuff, i thought it's gne for good now, with no traces except maybe on some unkown server logs.

I maintain some 100 folders or so, but the file contaied probably in the thousands. Because i chose 'telling' folder names, it represents kind of a history of all my mail activities over the past 15 years.

I just deleted the file, including the bak, right away, but now i need to reconfigure all those 'default account' settings, and colors, and templates. Which i leaned on a lot.

I know that special privacy requires special measurements, which i are willing to do only to some limited degree. The point is that i don't like the idea of my mail history (obsolete IDs and folder names) 'archived' in one central place (which is claws in my harddisk), not because i've got so much to hide, but rather by principle; and yes, i fear some kind of trojan sniffer or local attacker. 
In a nutshell, it means i can not trust claws.
Please think about a fix.
Comment 2 George 2018-03-20 02:05:52 UTC
Michael, you may want to check bug#3982 as it has the same privacy implications which you may want to clean up. *.bak and *_history files could also be considered a privacy issue and IMO there should be an option to either not create them or automatically delete them (in case the program closes normally without crash). Otherwise one could manually link them to /dev/null but that is rather an overkill and may not work properly.
Comment 3 Paul 2018-04-04 08:01:54 UTC

*** This bug has been marked as a duplicate of bug 3952 ***

Note You need to log in before you can comment on or make changes to this bug.