I tried to reduce space on my internal storage, but had no success. Moving the whole app to sd-card did not work. The occupied space on the internal drive remained unchanged. Also deleting chats did not reduce the space. Where are the files stored? How is it possible to reduce the occupied space? Under archiving I understand just a rearangement, to make the list of chats shorter. Maybe it would be possible to move the archived chats to the external sd-card?
Maybe it would be possible to add an option to clean up a chat? Now I can choose between archiving a chat or deleting a chat. As far as I understand does archiving move the chat to an archive folder to keep the chat list shorter? Deleting leaves the messages on the server, but deletes the groups.
So it would be nice to have the possibility to delete the messages of the chat on the phone but leave the messages on the server and leave the chat empty? So I can clean up a group conversation but do not need to delete them.
archiving does not help saving space on the device.
but we will add a function to delete old messages in one of the next versions, it’s not 100% clear yet how exactly this will work out, however, the issue is known and will be worked on
please look for similar issues at github issues for delta chat core and android.
There are some issues related using disk space, database compression, storage location and automatic delete (archive) of chats. One issue I imagine just now is “limit retained history” or the discussion related database “vacuum” function.
So far …
of course, it is great if users look up on gihub and it is a good idea to point to this here.
however, in general, it is fine to post here without even knowing that github exist
this allows broader discussions without the need of a technical background.
Thanks for your input! I found the topic “Extensive memory usage on backup import” https://github.com/deltachat/deltachat-core/issues/261 but this is not the point.
- One point is the possibility to put the data on the external SD card and
- another point is, if I delete a chat with many pictures and videos I expect the size of occupied data to be reduced.
If you want I can open new issues on github?
As workaround maybe I uninstall the app and install it fresh and empty again, this is no problem, but no solution. The workaround to vacuum the db on my PC looks complicated as I dont have a sqlitebrowser and is not suitable for a 08/15 user.
it’s totally fine to discuss this here.
the sd-card will probably not supported soon (or ever) by delta chat directly. there are lots of issues with that, among them security problems.
however, newer os support to expand the internal memory with the sd cards, and, of course this is also supported by delta chat then.
but, again, a function for cleaning up is already planned, you can track this issue here: https://github.com/deltachat/deltachat-core/issues/244
are the local file attachments not deleted if a chat is deleted? If deleted, most of storage occupied by a chat should be free’d again. Free of database file space is another issue (vacuum) but I think this is not so important than deleting the big file attachments!
Shure, for a proper solution we need both
files belonging to deleted chats currently stay in the blob-folder currently, the plan is to have a garbage collection that checks for unreferenced files from time to time, however, it’s just not done, it’s strongly related to https://github.com/deltachat/deltachat-core/issues/244.
if messages are deleted, however, the belonging files are already deleted if they are no longer referenced.
nb: the same file can be shared by different messages, so a 20 mb file that is forwarded takes up only one time space.
in general, there is also the idea that the blob directory is no longer used at all and all blobs are stored directly in the database. this would (a) make housekeeping easier and (b) make at-rest encryption easier (https://github.com/deltachat/deltachat-core/issues/194).
i’ve just filed a separte issue for housekeeping: https://github.com/deltachat/deltachat-core/issues/484 - if anyone has experiences with sqlite and larger database, please speak out loud here or in the issue
I don’t think it would be a good idea. When you deleting record from SQLite database, it won’t reduce size of database file. SQLite just marking deleted space as empty for future “inserts”. To reduce actual file size of database, it would be required to run periodically “vacuum” procedure that will drain uselessly battery. Database should keep only references(path/file_name/modified date/may_be_hash) to blob files that should be handled by operation system, such as attachments/images/etc.
I think that functionality that exists in K9mail to set number of recent messages that kept offline on device - is a way to resolve this issue. If one need to read older messages, he/she can use search that can run on the server side and also may explicitly pull old messages by pulling screen down as it works in another mobile clients
BTW, SQLite won’t accept single blob file if it’s bigger than 1Gb and it’s hard-coded limit.
Technical background of DC:
Blob files are only stored in database when exporting a backup. While importing these are deleted again and vacuum is done afterwards (This is a problem if storage is short at device!).
With an installed DC no blobs are stored in database. Files are stored in blob directory as files!
The vacuum process in the moment is only started after importing a backup file. While normal operation of DC this is still not available for a user (May come in future versions).
My experience up to now shows that most storage space is occupied by blob files outside of the database. In fact, vacuum could help to reduce occupied space of the database itself, but blob files are feeling to me more important to delete them in case of a “delete process” in DC. I don’t know if this is done by DC in current version.
My experience is still based at v0.20.0 (!)
@r10s - I hope this is correct ?
just a small note: the upcoming delta chat version will delete blobs belonging to deleted chats
First I have to discourage anyone to use the feature of Android to integrate the SD-card into internal storage. As experience tells me that construction will fail sooner or later & you’re struggeling to recover the encrypted data if you don’t have a backup.
Secondly I don’t get why nearly all apps don’t allow the user to move it’s database to the SD-card. All the time I get access to other peoples devices I see they are nearly out of internal storage yet their external SD-card has tons of space left. Why not warn the user about security concerns and then let him decide for himself?
Manyverse, a client app for the decentralised social network Scuttlebutt, has to deal with potentially very big local storage demand and already supports putting it’s database on the external SD-card.
So I’d really appreciate Delta Chat giving the option to store data on the external SD-card!
DC already has external storage - IMAP server(that can hold practically unlimited amount of imformation), so IMHO it isn’t necessary to keep all emails locally on device. As I already mentioned here, DC-mobile should keep defined number of messages locally on device base on (future?) preference 100/250/500/all as it done in K9. If user need old messages, one can pull it from IMAP in the same way as it works in K9 - by pulling down message list down.
While text won’t take a lot of space and can be kept in sqlite database locally, it isn’t a case for blobs that takes a lot of space and early or later everyone will step on this issue. IMO DC mobile apps should keep locally on device only cached blobs base on some settings - “how long to keep blobs” locally: last 100/250/500/ALL messages and allow to pull old blobs from IMAP if needed when user scrolling to old messages.
some people have only 100MB of space in the email server and want to keep the messages in their phone, anyway not sure if there are someone interested in keeping messages older than X months
Judging by my XMPP client usage it’d keep all messages on the phone. I often search through my XMPP database on the phone for messages several years old.
dude live the present!!!
(hahaha just joking)
All businesses we working with, requires us to keep absolutely all emails on the servers. If DC would be used in such environments it will choke at some point for sure.
we are not talking about force the user to delete messages, just to give the option to do so, you have the need to keep the messages but we have the need to delete them, you will not need to do nothing the default could be to keep them forever