Tools -Export picks random folder
Dear Tbird folks, I'm on Thunderbird V78.8.0 on Windows 10. I want a way to save all my address books. I selected All Address Books and then I selected Tools -> Export and it opened a Save dialog pointing to a random folder and started saving files. I could not stop it except to keep pressing Cancel for each address book until it ran out of books to save.
This seems like a flaky way to save things. Why was there no option to pick a destination folder? I then selected one address book and used Tools --> Export and it behaved properly. But that's the slow and tedious way to save all of them.
How is it supposed to work when you want to save All Address Books in a row?
Yours, Michael F
चुने गए समाधान
Yes, it looks like an address book with lists, when exported to LDIF, retains the lists, and when the LDIF is imported, the lists and their contents are present in the imported book. When I did similar tests in the (distant) past, before the format was changed from .mab to .sqlite, the lists were never kept, so this is a welcome change.
संदर्भ में यह जवाब पढ़ें 👍 0All Replies (5)
All Address Books is not an address book associated with any particular file in the profile folder - it's more like a search result. Better to save each one separately, as you did, or save the sqlite files in the profile folder that are address books, e.g. abook.sqlite, history.sqlite, impab.sqlite, abook-1.sqlite etc. But it's better to export them from Address Book as LDIF files, since these are easier to import. If you have many mailing lists, saving the sqlite files preserves the lists.
Dear sfhowes, Thanks for that explanation. It would be helpful if the UI said to NOT try to export "All Address Books."
I found that, if needed, the ldif files are easier to read than the csv files, so I'll save them that way.
Do you know why the Export command uses the address book name when it creates the ldif file but the Thunderbird profile stores them as abook-1.sqlite, a-book-2.sqlite, etc? I opened one of them and it looks like thousands of empty lines but they are all 327,680 bytes in size. Also there seem to be three extensions per address book: .sqlite, .sqlite-shm, and .sqlite-wal. Why is that?
<<If you have many mailing lists, saving the sqlite files preserves the lists.>>
I have address books and create distinct mailing lists from each one. Are you saying that if I save an address book, it doesn't save the associated mailing list? Do I have to save each mailing list as well as the parent address book?
Yours, Michael F
I don't know why the names of the profile files does not indicate the name in TB. Personal Address Book is always abook.sqlite, and history.sqlite is always Collected Addresses. I don't know the purpose of the shm or wal files.
If you save an address book with lists to LDIF, then view it in a text editor, the lists are absent. Lists can be exported, but only imported as address books. Backing up an address book with lists by saving the sqlite file preserves the lists, but to import it, its name has to be changed to abook.sqlite.
Dear sfhowes,
I did an experiment with one address book (EDC people) and its mailing list (EDC members). I exported both as LDIF files, renamed the files in the address book, and then imported the address book only. The address book reappeared along with its mailing list!
I looked inside the address book LDIF file and saw at the top a block of data that contained the names in the mailing list. This was followed by more detailed data on each name that is in the address book. (I sanitized the actual names.)
Could this mean that the subordinate mailing list is being exported inside the address book? If yes, that would be a wonderful feature.
dn: cn=EDC members objectclass: top objectclass: groupOfNames cn: EDC members member: cn=name1,mail=e-mail address1 member: cn=name2,mail=e-mail address2 member: cn=name3,mail=e-mail address3 member: cn=name4,mail=e-mail address4 member: cn=name5,mail=e-mail address5 member: cn=name6,mail=e-mail address6
Yours,
Michael F
चयनित समाधान
Yes, it looks like an address book with lists, when exported to LDIF, retains the lists, and when the LDIF is imported, the lists and their contents are present in the imported book. When I did similar tests in the (distant) past, before the format was changed from .mab to .sqlite, the lists were never kept, so this is a welcome change.