[DavidTC]

So yes, given what we know today, a large majority of people do not send their entire library to CC.

Fair enough. I don't understand why, but fair enough.

I am not sure that you have internalized that books in libraries synchronized by a cloud provider are almost certainly not "calibre books". Their internal metadata is not updated.

I do not understand what you mean by 'Their internal metadata is not updated.'. Any book that has been in Calibre has its internal metadata 'updated' at least once, when it was added. (Assuming Calibre supports the metadata, but, if not, all this is moot.) When it was added, at minimum, a UUID was put in, allowing an easy re-match to that book if discovered elsewhere.

That is what I meant when I said 'I would stop there'....if that UUID doesn't exist, the file has never been in Calibre. (A UUID that doesn't match anything also shouldn't be farther matched, especially since a likely setup is that it's from *another* Calibre library the user has.)

Anyway, stepping back from book matching a second, my point is that books can, indeed, have their correct metadata, and it is possible to know when that is.

There are several possible situations non-standard 'cloud' (aka 'books exist in the Default path that CC does not know of') situations:

1) Pointing that path directly at a copied (however) Calibre library. This can't work easily for importing books, because the books have crappy metadata. This is what I started with doing, and I'm slightly worried you keep basing what I'm talking about off it...except that I have no problem being #3 instead. In fact, I like #3 better.

2) Pointing that path at...a folder that has random files that have never been in Calibre. This...is an entirely different thing that I am not making any suggestions for at all. (I personally would just shrug at them, but that's me.)

3) Books sent via the cloud 'Folder device', or via direct device connection, and ending up in CC's Default folder. This always have correct metadata, because they are sent via 'Send to Device'. They're just sent in a *different* way than the wireless device connection.

It is #3 that I was going to make a case for supporting. (With a flag set to indicate they actually were 'Sent to Device' like that.)

The usual path is something like a book store where one is strongly encouraged to download books directly to the device and separately to calibre.

That requires them to have their CC Default folder pointed at the book path their store uses. That, *by itself*, is pretty broken:

What happens if they remove the book from the device using CC? Will the device's 'store' handle that? What happens if CC puts it back, but in the path that CC wants? Will the store find it? And now what if they decide to 'archive' that file in the store (Aka, delete the file off the device)...now CC has files that don't exist and they have to delete books with missing files.

They've basically got two different programs reading and writing to that directory, one of which (CC) *definitely* won't see additions by the other, and needs to be prompted to see deletions...until it does see additions, semi-randomly, because it was connected to a computer. And the other program (Being a proprietary store) is probably the same way, with the added fact it probably has no 'matching' ability at all! That is the ultimate setup for confusion.

That's one of the reasons I said I'd throw my hands up at any files that don't have a Calibre UUID.

And that's just what's going on *on the device*. Running around additionally downloading books on a computer is just adding to the situation.

Another case arises when people use their reader app to download books.

That would just make one copy, which doesn't need to be synced with any Calibre book at all...the user just needs to copy it off the device into their library. My point was more the oddity of having two independent copies of the book. I understand the copy starting on the book.

...oh, wait, what happens if they copy the book up, but they have automatic metadata sync turned off? I guess they'd have to *rematch* the book...again and again...on every connection. No, surely that can't be right.

A related case happens when people reset their device or clear app data because of some problem. And finally, and as I said above, books sync'ed to the device directly from the calibre library (no "send to device") usually don't contain (correct) calibre metadata.

Well, no, but in both those cases the files would contain a Calibre UUIDs in their metadata.

It is also worth noting that many (most?) pirated book collections are generated using calibre. Sometimes the books *do* contain calibre metadata, but it is metadata for the pirate's library not the user's library.

Heh. I literally deleted a section on pirates in my last two posts addressing exactly that.

To start with, this situation is hard to get to. I suspect that pirates use 'Save to Disk' instead of 'Send to Device', and that's why I *didn't* suggest having 'Save to Disk' add that flag, despite that metadata being correct also. Next, the person who *downloaded* the copy must, instead of importing it into Calibre, would have to somehow get it into CC Default folder directly, which is odd behavior.

But, assuming all that, they now have the file imported into CC without it being in Calibre.

And this...isn't a real problem, as far as I can see. Books can already be in CC without being in Calibre. It's called 'deleting them from Calibre' or 'Using multiple libraries'. (And that second even allows entirely different metadata fields! Although you can't actually use them in CC.) It doesn't seem to cause any problems.

If they want to edit the metadata, the solution is, as always, that people to put the book in Calibre! (As the pirated book file already has a Calibre UUID, they can even just copy that into Calibre and it will magically match the file already on their device.)

Again, I'm not saying allowing this import is actually worth supporting. I'm just pointing out it there is some subset of books where you *could* safely read the metadata from them, if Calibre added a metadata tag like that during Send to Device. The pirate situation would be pretty rare and odd and the answer to 'How do I edit this wrong metadata on my pirated books?' is 'Like you always do...in Calibre. If the book is, somehow, not in Calibre, put it there.'.

Meanwhile, *most* pirated books *wouldn't* be importable via that means, and in this hypothetical CC probably popped up something saying "For CC to import books directly, they must leave Calibre via 'Send to Device'. You cannot copy non-Calibre books files directly here, or even use them straight from the Calibre library.". So I'm unsure why people would even *continue* to attempt directly copy downloaded books there on the off-chance it would work.

Actually, frankly, having that flag in 'Send to Device' books (And a different one in 'Save to disk' books) wouldn't be a bad idea even if there were no changes in CC.

I can't get on my high horse and tell these putative pirates to pound sand because there is at least one legitimate reason (I am not saying "legal") for grabbing pirated ebooks: fair use, where the user owns a paper copy.

Sometimes it's even more legit than that, like when the ebook hasn't even come out and people have disabilities that prevent them from reading paper books. This is usually obscure things, but for a very long time Harry Potter wasn't out in ebook.