Thunderbird Address Book Import csv in v68.10.0 This is a more of statement for a developer rather than a question, but it worked. 1. Create a newly named address book in the left-pane. 2. Highlight the new book. 3. Tools > import > csv > find ThunderUp2.csv 4. Click the proceed button. 5. Thunderbird reports successful import, but . . . 6. No data. What did occur however, is another new address book appeared in the left-pane entitled "ThunderUp2" (minus the .csv), obviously named after the import file. Unfortunately, both of the new address books showed no contacts, nevertheless, a file search produced two new *.mab entries in the roaming\profile sub-dir, impab.mab and I forgot the other, maybe impab2. Anyway, both of these new files indicated zero bytes, confirming exactly what I saw, nothing in either address book. Anyway, without touching anything (leaving both new address books in the left-pane), I re-imported "ThunderUp2.csv" into the new address book entitled ThunderUp2, both with and without the "first row contains header" option several times - no success. Then I modified ThunderUp2.csv by inserting a header row (the category names) and then tried both combinations of "first row contains header". Eventually, one of these latter combinations imported the data into the address book entitled ThunderUp2. With that accomplished, its seemed safe to delete the first new address book that contained nothing, and now, a quick search of c:\ *.mab confirmed there's only one new book (impab.mab), as well as the original two default books (abook.mab and history.mab). The import process seems a little clunky. Note: At this point, I suppose renaming the ThunderUp2 address book to whatever one desires is an option using the menu options. The good news is the import process mapped the data fields correctly, including the birthday fields. One surprise, however. Although ThunderUp2.csv included both a "first" and "last" name, I purposely did not include a "display name" (entered this instead ,,) in order to determine if it would populate "display name" by combining the first and last data fields, something that occurs automatically when manually entering new contact data. It did not, but first and last names were still in data file. Instead, the "contact summary header bar" (above the contact's photo) displayed the data field "work organization", rather than marrying the first and last names into a person. It appears that unless there's data in the "display name" field, it assumes its an organization, a clever but un-obvious substitution, probably causing more confusion that its worth. This test was produced by manually entering unique text in every data field (text describing the particular slot), then exporting the book as xxx.csv. Next, take the exported file apart in excel and append the text from each data field with an arbitrary suffix (the numeral 2 in this case) to create ThunerUp2.csv. This confirmed the import feature correctly maps the data fields since all the data fields indeed re-imported with a suffix of 2. Maybe someone could improve the shenanigans required to ingest the csv file, and don't forget to populate the "display name" data field if its a person. The original exported csv (from the default address book) and the re-imported ThunderUp2.csv contained only a single contact, something possible since this is a fresh install of v68.10.0 on a new machine. One caveat, the typical user is likely to import their csv data into the default address book (abook.mab), rather than a newly named address book, which might produce different behavior (and more confusion than necessary), but based on the chatter, it appears others are having issues importing contact data. abook.mab (default address book) history.mab (automatically stored replied contacts?) impab.mab (import address book) After inspecting the contents of the above .mab files, its clear that none of them contain their external file names, or the name of the address book that uses them, making moving them problematic (probably causes a crash of some sort). Hence, the numerous and confusing descriptions of how to move, copy, rename or backup the entire profile directory in a manner that keeps the address book bundled with its co-dependent files, and then re-queing the application to find the moved profile directory. This is just a guess of the actual process, but it seems unnecessarily confusing when there's 12 different conflicting examples of how to accomplish the task. All I really want to know is what precisely constitutes a functional back up bundle, and what bundle can be safely erased without causing a crash, in case the FBI shows up uninvited. If you get this far, there's a couple pictures. ThunderUp2.csv is actually displayed on screen as ThunderUpload2. One pic is the original exported cvs with the name of the data field, ThunderUp2 confirms all the data fields include a 2 appended in every field, but in organization view instead of a person.