Close the round-trip export/import loop for LT data.

Now that LT has good support for importing the export files from Goodreads and Shelfari, so that all of the hard-entered information in those export files can be imported, perhaps they could consider doing the same for importing of LT's own export files. I've spent a great deal of time carefully editing the data in my catalog (and am far from alone in this respect) and, frankly, if LT had a catastrophic data loss such that I had to restore my catalog from my backup file (which I download once a month), I probably wouldn't bother - the so-called "Universal Import" throws away so much data that I'd be better off manually importing everything from scratch, or just rolling my own offline database.

A backup without a way to restore from it is not a backup. I appreciate the export file, but have no illusion that it is a backup - it's a way to start over on my own if my catalog ever gets lost, not a way to restore my LT catalog. It's a shame that LT has devoted so much time and energy to helping people import data from their competitors without ever devoting that same level of effort to helping people import data from LT itself. I don't even care which format(s) are supported, as long as I can get all the data back in I'll happily download the JSON or MARC data.

This lack of a true backup has niggled at me as well. I've read that LT servers are backed up quite robustly. I suspect I'm adhering to an outdated model when I think I'm responsible for my own data, rather than trusting the cloud to provide data integrity for me. For pretty much any other web-based site, I leave it at that (prepared to start all over if something catastrophic happens).

LT is the one place I want to take extra measures. I don't do a monthly backup like lorax does, but think I should. I'm very unlikely to recreate my catalogue outside of LT, however. I would feel much better if LT allowed full import of my catalogue -- at least, the private data (excluding Common Knowledge).

I still think the principle of decentralized / distributed backup files is the most secure and most reliable way to preserve data.

Yes yes yes!!!

Please, yes!

Even a custom - non-editable - export format only for import would help, if you want to be sure no ratty data imported.

Most important would be that it would not lookup anything on outside sources. Import as is.

Most important would be that it would not lookup anything on outside sources. Import as is.

Yes. This was, I think, sufficiently core that I didn't even think to mention it, since "look up a bunch of ISBNS and import library data for them" is available now, but it is absolutely required.

I just had an idea about minimizing /lessening possible bad import dupes etc:

What if the export contained the bookID, and just overwrote the book-data of that bookID on import again?
any records with book-id's in the data not currently in your catalog on LT would just get ignored. This way you can't just overwrite bookID's from other peoples catalogs.

just spouting ideas.

+1
This seems like functionality LT should offer out-of-the-box.

Bump.

Maybe I need to be a church library to get a response? The guy asking about ResourceMate heard from Tim immediately.

This is definitely high on my own personal list of ponies, so I hear you! Wanted to chime in to let you know this has been noticed.

Bump.

Bump.

Bumbity bumb

Bum-bity-bumb-bum, bum-bump.
Please.

Bump.

Bump.

Almost one year on, I'd still like to see this RSI implemented. So: bump.

Bump.

8Petroglyph
Mar 15, 2016, 3:30pm
+1
This seems like functionality LT should offer out-of-the-box.
That's what I thought from the beginning - and was astounded to find it wasn't so.
I have a couple of exploratory and family-members libraries that I am holding onto until this happens, so I can combine them with my primary account.

maybe we bumped it to death.
10kristilabrie are you still there??

>19 librisissimo: If you want the little link to the post to which you are replying, type a caret > and then the post number with no space in between. LT will do the rest.

Bump.

It was suggested I bring this suggestion over from
https://www.librarything.com/topic/260411#6092649
This is the list of suggested changes to LT. I repeat it here.
=-=-=
The list surfaced an issue that has caused me thought and some consternation over the years. Allow import of data to use the field names (created in LT) as a heading for each spreadsheet column and then allow the columns to appear in any order. It would allow people to pick and choose what they want to import.

This would help many new people understand that they might be able to import just what they want to use and not have to try and create the whole world.

I'm from the school of "use what works for you and ignore the rest." That is how I have run LT for my collection. I may be stating the obvious here but that never hurts as a way to get new people into LT.

Please ask me for more detail. I guess as much as I dislike Access, it does have a couple of things in the table structure that make sense for use in the import/export area.

This would help many new people understand that they might be able to import just what they want to use and not have to try and create the whole world.

That is, of course, not true now. I wish it were, and as you say it could be tied into this RSI, but it's a matter of that functionality not existing, not of people not understanding its existence - either you manually do everything, or you get the paltry few fields LT can import and do the rest manually.

Bump. Another question reminded me of this.

Bump. Again, reminded of this by another question.

Bump!

Bump. Reminded of this by a request.

Bump from a new suggestion:
https://www.librarything.com/topic/272639

I'll repeat my comment from a year and a half ago: >8 Petroglyph:

This seems like functionality LT should offer out-of-the-box.

Or, you know, bump.

So, now that Other Call Numbers have been added to the .csv import, can we expect the import/export loop to be closed soon-ish? In less than "two weeks"?

Unfortunately, I suspect that addition means they're less likely to actually fix this feature, if they're inclined to pick random tangentially-related fixes out of a hat rather than deferring them for a real fix.

Still, it can't hurt to indicate that there's still interest in this feature.

I have been here almost since day one. I export my catalogue monthly, and have spent a lot of time making sure everything is complete and correct. If there were a catastrophic data loss, without being able to re-import my catalogue, I wouldn't bother to return.

Season's bumpings.

>31 lorax:
Deferring the issue indefinitely, or onset of an actual fix? I would prefer to give them the benefit of the doubt.

Oh good grief. I've been here 12+ years myself, and it had honestly never even occurred to me that this would be an issue.

(Or, you know, bump.)

Bump.

I posted the following in https://www.librarything.com/topic/290737 in Bug Collectors, but it was pointed out to me that it is not the result of a bug but down to how the export / import works. So I'm reposting and joining this discussion.

I'm not sure if this is a bug or just the way things work, but I scanned some CDs into my 'humouress' account using the LibraryThing app but then decided I didn't want it there and exported it to my 'libraian' account. Now that it's been imported into my 'libraian' account the cover image, author (aka artiste) and publication fields didn't make it across. Even if it didn't pick it up from the import, shouldn't LT have picked it up from the barcodes I scanned?

And I notice that the number of members are not the same. For most of them in 'libraian', there is only 1 member but in 'humouress' the records show different numbers (and don't include 'libraian'). For instance, Graceland shows 3 members under 'libraian' but 111 under 'humouress'. Aren't the records tied together?

So, the "number of members" part is an unrelated combination issue. Cover image, publication, etc. not importing is as (badly) designed. Author not importing is due to the source you used; LT will discard even fields present in your import file if the source has something for that ISBN.

>37 humouress: humouress,

I do think that the recent weekend offline and small segment of data loss reinforces the importance of having user-level export and import for the purpose of making a backup without LT staff intervention (if it is even possible for them in some cases).

Thinking about your situation of moving a record from one account to another, the first thing that comes to my mind is that your entries are not a data source so far as LT is concerned. So edits you have made to your own records are not candidates for the usual "Add books" functions in LT.

I can think of a way to achieve this but it may not be something you care to do. It involves using Chrome or Firefox as your browser and installing the TamperMonkey or GreaseMonkey plugins, respectively. To those plugins one can install the LT user created script called "LT Copy Book".

When this is installed and running a detail page you see (from any user account) will have a button added that will let you copy most fields of the detail record into a blank "Manual add" form. When this form is submitted, the record will be in the active account.

So, to do this, you'd need to be logged in to the account where you want the records to be added. Then navigate to a detail page of a record you want to copy (in your other account, someone else's account, the same account, etc.).

The image below shows the script in action. In this case, I was testing it on a record from my own account.

If you find that this workflow is something you want to try, we can discuss the details of installing the plugin and script. Keep in mind that there's always a chance that a script like this will be "broken" (nonfunctional) if there is a change on the LT site that affects the way the script "sees" the detail page for a book record.

James
_____

Oh dear, now we're getting technical and I have to start using my brain ;0)

>38 lorax: My situation is not quite the same as yours in >1 lorax:; I don't think I edited my entries after scanning them into 'humouress', so I was surprised that there was so much loss of data. There aren't many sources available when scanning in with the app, so I would have thought that all available data would go through. It'd be much more heartbreaking to lose data entered in personally.

>39 Keeline: Thanks James. That sounds like something I should get around to installing eventually. For now, I think I'll just delete the entries and scan them in again. There were less than 30 and with the app, it's usually quite fast - once you've discovered the right distance and angle to hold the camera.

So wish we had this feature of full import!

Bump. Since there have been a few digressions lately, let me link back to the first post on the off chance that a staff member stumbles across this thread.

Bump. Not gonna let this go.

I'm guessing work on GDPR compliance and the Privacy Center will contribute towards this goal.

Hollow laugh. The export is fine, it's been fine for a long time. It's the import that is lacking, and I don't think anything in the GDPR requires users being able to re-create their personal data if it's inadvertently destroyed.

If we offered to pay the developers to implement this RSI, would that help?

Bump! Wouldn't this make a lovely Christmas present?

Bump. The export format should match the import format, and the import should just import what's in the file.

https://www.librarything.com/topic/302271

>48 r.orrison:

To be clear, the *import* format should match the *export* format. I very much do NOT want the export format to be reduced to only include what currently is in the import file - that would be catastrophically bad.

I happened to be on the "Import" page and noticed this:



I've got a special format I'd like parsed. It's just a CSV file, but it has a lot of fields. Is this something that LT would be able to handle? ;-)

And again, someone very sensibly attempts to import the export file, fails, and wonders what's going wrong that the site doesn't offer such very basic functionality:

https://www.librarything.com/topic/208174#6764837

Bumperino. https://www.librarything.com/topic/305071

I'm also wondering why, when I scanned in some books via the app and they showed covers (presumably from Amazon) on the app, they didn't produce covers on the website.

One reason given was that there were no covers available on the website (huh? so how comes there were covers on the app? The correct ones, too.) so I ended up scanning in my covers to save time. Not the best result, but the fastest.

Bump. If people are going to be deep in the code anyway, maybe this is something that could get a look.

Bump. https://www.librarything.com/topic/309419

I bugged Tim about this at an in-person meetup in June but I don't know if it worked

YES yes yes: agree totally with (1) lorax: many of us spend a lot of time editing our records to reflect our needs. It is laughable that LT won't allow us to use the exported data either as a backup, or for importing parts of it into another L/T catalogue! I note that this thread began in 2016 - as you can see, nothing's been done in 3.5 years.

Just to add another voice: Mmhm, yes.

It's mindboggling to me that we don't have the option for a complete backup file, despite Tim saying this was one of his project ponies years ago.

Meanwhile, we (some members) are given pop-up cover previews, as if that minor convenience was a bigger priority than ensuring we don't lose all our data during a lockout, system glitch, etc.

Bump: https://www.librarything.com/topic/313376

Bumpty bump. It's kinda scary using LT without this feature.

Just noticed this thread, so, BUMP, and also, I added a new RSI here:

http://www.librarything.com/topic/314495

Bump. The lack of basic functionality is quite rightly turning off potential new members with extensive catalogs:

https://www.librarything.com/topic/314495#7079950

>31 lorax: "I have been here almost since day one. I export my catalogue monthly, and have spent a lot of time making sure everything is complete and correct. If there were a catastrophic data loss, without being able to re-import my catalogue, I wouldn't bother to return."

>62 lorax: "Bump. The lack of basic functionality is quite rightly turning off potential new members with extensive catalogs:"

What lorax said, both times.
In addition to the thousands of books I've already entered in LT since 2009, I have thousands more books on a set of spreadsheets that I could reconfigure to the LT fields format and add automatically with a proper Import function, whereas it would take me years to import them with the existing function and edit them manually.
It might need to be a separate function (called Recovery rather than Import?) as we aren't actually wanting to look up ISBNs etc. and add NEW books to our account.

>46 Petroglyph: "If we offered to pay the developers to implement this RSI, would that help?"

Actually, with LT being free to individual users now, maybe we could set up an improvements fund as part of the donations function to help hire more developers for things we would really like to see done but just don't make it to the top of the list. Kind of an internal GoFundMe sort of thing.

Of course, if this has already been done for the new LT2 release, then just accept our thanks.

>63 librisissimo: that's an RSI in itself. Imagine a system where we could buy LT dollars and we could use to crowd fund RSIs we want worked on.

Maybe something like Patreon, you can poll your crowdfunders on this platform.
https://support.patreon.com/hc/en-us/articles/360028159232-Poll-my-patrons

>46 Petroglyph: >63 librisissimo: >64 wifilibrarian: Paying money to get RSIs done won't solve the fact that they have only 2 developers on staff to do all the work. Unless we specifically raise enough to hire about 10 more developers at a full time salary for 5 years.

Bump.

>66 lorax: Yes, this should be a much bigger priority than the cosmetic updates IMO.

>67 Opteryx:
The current updates don't seem to be cosmetic only, even if the most visible effects are only, well... visual. There are deeper changes on the roadmap if I understand correctly. I don't think the LT staff has mentioned this very important issue in their recent messages, but perhaps we can hope the current clean-up will lead to a situation where it can finally be addressed?
Anyway, a broader concern of mine is that for the past handful of years I haven't seen much evidence that the LT staff is actually monitoring what is proposed in this group :-/ I'd love to be proved wrong!

>68 Felagund: This RSI is a personal wish of mine, too, and yes we do monitor this group. :)

I foolishly yet wholeheartedly attempted a major undertaking of the suggested features in this group when I first started here about 6 (wow time flies) years ago, before realizing how limited our developers' time was and that timspalding has a pretty clear vision of projects that need to be done and when. My impression over these years is that there's sometimes a suggestion posted that hits all the "right notes"—it's a great idea, has a lot of sway with members, and is an easy win for us to implement—but mostly this group is for fleshing those ideas out. Lots of fruit falls off the tree (and oh dear this one is rotting I'd love for us to just pick it already) but some does make it ripe for the picking.

All this said: we are actively looking to add on a new full-time developer, and I hope that once that happens it'll mean, even just a little bit, more time available for improving features such as this one.

>69 kristilabrie:
Thanks for this kind explanation of the situation in the RSI department :-)

Bump.

Any news about new hires, and hopefully increased development power to address long-standing system issues such as this one?

Bump: https://www.librarything.com/topic/333858

Bump. What >1 lorax: said.

I can't think of a single feature that is more important than a full import/export loop.

After being a member for some years, but with just a few books entered, I'm finally getting more of my library input, and without a doubt I would be much less inclined to do so without the full export. However, as has been stated, if there were a loss of data on the server side, there's no way I would reload from ISBNs and redo all the manual entry. I would probably either just use the excel file as my catalog, or try to find a self-hosted solution.

From a non-backup data entry point of view, I have been using the .csv import quite a bit, and while I am thankful that we can upload tags that way, I found it incredibly frustrating that any other data I entered (especially dates, which are frequently wrong in the catalogs for the books I was entering) were overwritten. And honestly, that behavior is not well enough documented--I wasted a fair amount of time trying to figure out what was going wrong.

A side effect of this is that all of my shelving information (as well as other details, like reprint date) is located in my tags. And there it will remain, unless we get the ability to power edit some other fields (like "other call number system"). (It took a lot of willpower not to abuse the "review" field.)

I really like LT--it does so much, so well, and I don't think there is anything else that is even close. And it's free! And even when it wasn't, it was cheap for what we got. However, while there is always room for improvement, and I look forward to other improvements that occur, the import functionality is the only thing about LT that I would unequivocally characterize as a flaw.

New bumper bumping.

>74 sausage_mahoney: "A side effect of this is that all of my shelving information (as well as other details, like reprint date) is located in my tags. ...
I really like LT--... the import functionality is the only thing about LT that I would unequivocally characterize as a flaw."

Pretty much sums up my position on tags and reviews, but I would add "I love LT" and appreciate all of its current functionality. The improvements made over the years (I entered my first books in 2009) have been phenomenal.

So far I've entered around 7 thousand books into LT manually, but I haven't tried to import data since 2009, as I found then that a lot of it didn't transfer. I still have about 4000 books in old spreadsheets and could reformat those to "match" the LT fields, if I was able to port all of those fields across.

Indeed, lorax & others said it all in the first few entries in this topic in 2016.

That's a very long BUMP.

Bump. A member just tried to do this and was disappointed: https://www.librarything.com/topic/335695

>77 r.orrison: That would be me!

I support this bump.

>79 Felagund:
Me, too. A backup is not a backup unless it allows for a full restore (successfully!).

Bump bump bump. Urgently need restore from backup.

>81 tiggermark: This other thread has more recent discussion, including a comment from Tim here:
https://www.librarything.com/topic/335695#7620630

This is, however, still the thread of record. So, bump.

Copying and pasting from another thread, because Tim is being obstinately literal and deciding that because they cannot do absolutely everything they won't even bother to try to do anything:

The existing LT CSV export contains a number of fields, one row per book, in a row and column format. It contains most of the fields that I consider relevant and important and that I would wish to restore in a backup.

The existing LT CSV import contains a number of fields, one row per book, in a row and column format. It contains very few fields and is missing many that I consider relevant and important and that I would wish to restore in a backup.

If "Import the existing LT CSV export file" is a non-starter, may I ask instead for you to "Create an additional "rich CSV import" file that includes most* of the fields from the existing CSV export file"?

* "Most" because book ID and work ID would obviously be problematic and should not be imported.

https://www.librarything.com/topic/309419#7669668

"When I used LibraryThing to export the data, it never occurred to me that LibraryThing wouldn't be able to import that same file."

Bump. Because we mean it.

Case in point.

Petroglyph (#87):

Beat me to it!

I am still baffled at the official apathy for this feature. Is it because we continue to use the site despite knowing much of our catalog data can't be downloaded in our own backup file?

I wonder if it's because of people like the one linked in >87 Petroglyph: - full import would make it easy to duplicate a library across multiple accounts, or switch to a new account without deleting the old one. Is this Tim's old "we can't do it because it would proliferate bad data" bugbear hiding in the shadows?

(If so, it's silly, because the existing broken imports produce if anything more bad data.)

>90 melannen: I would say that if a full restore is ever needed then that will be the end of this site, because I doubt if many users will be willing to put in the work needed to restore everything they have already entered. A useful backup that can be restored only makes sense to have. The lack of one is just asking for problems. Ask any corporation if they would go without having a backup in case of data loss and I think they will all say that they would not.

>91 Bernarrd:

That we don't get complete exports doesn't mean that LT doesn't back up its data.

>92 cpg: I fully expect that LT has several kinds of backups and other procedures in place to protect data. However, catastrophic failures do occur, even on big companies. Consider Pixar that almost lost a version of Toy Story 2. As it was, they changed the plot and ended up ditching the content they rescued from an employee's home computer but this is the kind of thing that can happen.

In the early 2000s I was buying things from Disney Auctionears. They lost their database and pretty much shut down that division. At the time it was an interesting way to find and buy rare and unique items that they offered for sale.

Around the same time, a used book database I was listing on called BiblioFind.com had a hack where they lost information and they never came back. The other used book databases were never as effective as that one was for me.

So there are many cases with large companies losing important data. Trust but verify. I manage 44 servers and half a dozen high-availability database instances for my company where I act as the Linux system administrator so this kind of thing is forefront in my mind.

Plus, with proper exports and corresponding imports, it opens the door for local or server database installations using the data we have gathered and even offline phone apps.

Moving content from one account to another is another valid use case mentioned today.

Perhaps few people would use it but for those who would it would be very important.

Right now, the only way to import most of entries on a work-by-work basis could only be achieved by using Chrome/TamperMonkey with the LT Copy Books script (unofficial). This can copy most fields (not tags and not some other things) from a work detail page (that you are not logged into) to a blank Manual Add Book form page (for the account page in which you are logged in). This would be tedious to do for dozens or hundreds or thousands of books. It is OK to do for a dozen or so books and is still a time-saver for that kind of work.

James

melannen (#90):

I suspect it is because there are some things like book ID and work ID that could not be imported, so Tim has decided not to bother and instead to mock us for not understanding that LT is not just a spreadsheet.

>94 lorax: Yes, some things would need to be specified before just coding :-)
Also we have at least three use cases: 1. restore a record. 2. editing an existing record. 3. creating a new record.

Since this is just what existing library systems do all the time it should not be rocket science and "just do what the user would do in the web interface in this situation" would be perfectly fine.

Finer details like what to do with the work-id are interesting but for starters just ignoring it would be fine. I.e. if you try to import an existing record and the data is exactly the same as an export would give you, it can just be ignored.
And maybe a limit on the number of the records you can input pr hour or pr day, so spammers won't import a million spam records?

But as lorax can testify this has been a wish for a decade or so.

It is my understanding that the work ID is shared but the book ID is unique to a given member library catalog. Since most database systems like this use an "auto increment" feature, the usual way to handle it is to use a 0 for that value at the time of the INSERT and the next auto increment value is assigned to the database record. So this is not the obstacle that it might seem to be. This assumes that the record is a new one and not a replacement for an existing one.

As far as spam records go. When I was interested in the size of the larger libraries to see how mine compared (9,045 today), I found that a lot of the largest libraries were filled with thousands of minimal records of things obtained from sources like Project Gutenberg. Although there is no requirement that members enter books they actually possess, it does make it hard to make comparisons when there are so many books that can be imported. Likewise, some of the largest libraries were "private" in which case they should not be part of that statistical ranking. I stopped looking at that statistic because it did not have significance for me.

Probably some safeguards could be implemented to discourage import of more than 10,000 records at a time. If not this, pick a suitable number.

James

>96 Keeline: Yes, I ran across one user that has a wishlist of around 25,000 books which is most of the library. Nothing wrong with that, but I am sure that not as much work went into that as there would be listing a library with 25,000 real books. But I am sure this user would not want to lose his/her wishlist either.

>97 Bernarrd: It would be possible to obtain a list of ISBNs from Books in Print or Amazon, import them, and instantly seem to have thousands or even hundreds of thousands of books. Since there was no interest in managing this, that is why I decided that the statistic and ranking was no longer important to me.

I had hoped to find other people who live with 10,000 or so books since it is obviously a major commitment to select, purchase, ingest, catalog, shelve, and keep them organized. There is little connection with someone who has just a list of titles or a bunch of eBooks since the effect on one's lifestyle is different. I also have thousands of eBooks but I don't catalog them unless I have a physical copy.

This is all very different from the topic of this thread. I was only mentioning it to react to the "spamming" comment that might be possible with mass imports. It doesn't look like we'll ever get it so it is purely a rhetorical conversation at this point.

James

>98 Keeline: "I had hoped to find other people who live with 10,000 or so books"

Sorry, I'm currently stuck at 8495 :-)

>98 Keeline: I'm currently at over 13,000 but they are a mixture of media: print books, audio books, ebooks, DVD, CDs and vinyl. I've yet to catalogue boardgames - that'll be a project after I've finished cataloguing the sitting room - about 50 CDs to go, then 4 large bookcases which are part catalogued, and the 2 bookcases in the spare room (the comics are done, the bureau should be done).

Space constraints are driving the replacement of physical books with ebooks; there's also the issue that some books I have are, to put it politely, on the marginal side of being keepers. We're only likely to keep physical books we both like (we merged our libraries when we moved in together). The books most likely to be turned into electrons are those that only one of us like (e.g. my 1980s Regency romances or classic crime fiction or his hard SF).

Our new house (as of Feb. 2021) has about double the space that we had before. We are now up to 2,100 sq. ft. (195 m²) and have bookcases in four rooms and a bit more. Not everything can be shelved. Some items are back-shelved with like items. Some are still boxed. But we did get to add about a dozen 7-foot (2.1 m) bookcases similar to the oak ones we purchased in the 1990s for our previous home.

In addition to some 9,000 physical books, many of them vintage series books, we also have about 5,000 books of sale inventory. Our main way to sell books is in glass cases in two antique malls. Some of the inventory books are bought expressly for that and others are duplicates as part of our collecting. We use a separate LT account to keep track of the inventory books. Sometimes it would be nice to be able to move things back and forth between the accounts (topic of this thread). Right now if I want to, I 'd have to use the LT Copy Books script.

Maybe I should start an LT group for larger physical collections and see if anyone joins. It's hard to know just where to start a conversation about this. I know this is not the ideal place to do so.

James

>101 Keeline: Our new house (as of Feb. 2021) has about double the space that we had before. We are now up to 2,100 sq. ft. (195 m2) and have bookcases in four rooms and a bit more.

Colour me jealous :0)

>102 humouress: 156 m2 here and four rooms with bookcases. Two of the rooms with back-shelving i.e. two or three rows of books (mostly series of paperbacks).
Most of the books are shelved according to some system, but the system varies and is not part of the cataloguing, so we can move books around without having to change anything in LT.
I scan covers and record the physical size of the books, so I can recognize a given book by sight rather than call number.

151 m² and my wife thinks it's quite enough I've got one room with bookshelves ...

Over the last decade I've largely switched to ebooks and it's been a blessing on multiple fronts, not least storage space.

I'd love to have a discussion about large libraries, but can we please keep this thread on-topic?

Large or small, being able to properly back up our libraries is important to many of us, and this is a facility LT does not currently offer, which it easily could.

Back on topic, I don't see why regular members would care what the work ID, book ID, or other LibraryThing-specific details are.

When exporting, I expect the new file to include all data that may be manually entered to a LT book record. That's tags-- which I was entering into book tracking spreadsheets long before using online cataloging sites-- and not automatically generated markers.

Well, to be fair, one of the very few things that the existing import includes is tags.

I would like to see Collections, though that would be more difficult if someone includes a non-existent collection in the import file. But obvious stuff that is not there would be other authors, MDS/LLC classification numbers, physical dimensions, page count, rating, languages, comments both public and private, and the date fields. None of this runs into controlled-vocabulary challenges like Dewey / LC Wording or Subjects, or to UI / limited choice issues like Collections and From Where, so there really shouldn't be an issue.

>107 lorax: From Where shouldn't really be that difficult either, since it includes a free-text option - anything that doesn't match the existing list would just go in as Free Text. Also the From Where is a site-wide list. It seems like it should be possible to have a non-editable LT backup that can only be backed back up to LT - like was mentioned back in >05: - and any data in that file can be assumed to already work with the site-wide controlled-vocabulary lists.

Collections might be a little bit harder, but it is absolutely within a modern computer's capability to pull a list of all collections from the import, and then ask you to either match them to existing collections, or allow them to be created. Very few people have enough collections that this would be difficult.

I would like to have the member-uploaded covers for my books in the backup as well (in particular the ones I have uploaded myself). But I would be happy even with complete metadata only.

>106 aspirit: The Work ID allows you to automatically retrieve the work information to check if Other Authors have been confirmed.

It also makes it easy to find those of your books that belong to the same work. (Unlike authors because you might have several different authors with the same name and that can't be seen from the export file).

I'm not saying there aren't ways to do either of those. Just that it's *utterly trivial* to do the others.

Bump, because someone has now posted it as a bug:
https://www.librarything.com/topic/339514

bump.

Bump, because https://www.librarything.com/topic/348139#n8053479

Bump. I see rumours that the import / export code is being re-written or at least looked at. Please tell us this is part of the work!

Here's hoping!

Bump: https://www.librarything.com/topic/67295#8097244
Another user expecting that export then import will work.

Bump.

I'm interested in this RSI too

Bump with another thread asking for the same thing:
https://www.librarything.com/topic/351058

Bumping.

A backup is not a backup if you cannot fully restore from it.

Man, I wish this was a thing. I've been trying to find a workaround for this all day.

YESSSSSSSS! Still having nightmares about the mess the 2018 loss caused.

Also want our own scanned and uploaded book covers included in downloadable backups.

Bump!

https://www.librarything.com/topic/354037

Bump too

Nearly eight years. The world has changed, and this issue remains.