On a bluetooth-connected Nokia 302, the command “gammu getsmsfolders” yielded:
1. " Templates", phone memory
2. " Drafts", phone memory
3. " Saved messages", phone memory
4. " Sent items", phone memory
5. " Outbox", phone memory, Outbox folder
6. " Inbox", phone memory, Inbox folder
7. " User folder 10", phone memory
There were over 900 SMS messages in the “Sent items” folder. Also
hundreds in the “Inbox” folder. Both of these commands were executed
from a script:
$ (printf '%s\n' '/gammu geteachsms -pbk/:'; gammu geteachsms -pbk; echo) | tee -a "$textfile"
$ gammu backupsms "$backupfile" -all
There were 50 or so messages saved from the “Drafts” folder and 4 or
so from the “Saved messages” folder. That’s it. No msgs were saved in
folders 4—7 by either command. I saw that messages were saved and did
not bother to inspect the number saved from each folder. So then I
deleted all the msgs from the device. As it was taking the device a
long time to delete over 900 msgs in the “Sent items” folder, I looked
at the two backup files and they did not have a single msg from the
“Sent items” folder or the “Inbox” folder. Indeed, gammu apparently
silentely quit fetching without informing the user.
Data loss is one of the worst inflictions that users can
suffer. Defects like this should get a high priority.
I did not use gammu to delete the data because of an error. E.g.:
$ gammu deleteallsms 6
Deleting SMS from "Inbox" folder: Function not supported by phone.
So I had to use the phone’s UI to delete the data. In any case, it’s
critically important that these backup tools do some basic accounting
and give users a report like this:
Folder “Drafts”: 50 of 50 msgs copied
Folder “Saved messages”: 4 of 4 msgs copied
Folder “Sent items”: 0 of 950 msgs copied (incomplete!) <- in red text, ideally
… etc.