Bob asks: "popping the card out and inserting it into a reader that can be read by calibre allows all of calibre's synchronization features to work, might that not be good enough?"
That would be nice, and the Calibre folks are working at improving the situation a great deal! I started this post writing "Calibre can write files to a folder, but it doesn't poll a folder in the same way as it polls something it knows is a reader."
As I was replying, I took a quick look at Calibre to remind myself of how it behaves, and I think in a recent update they've improved the behavior (or I had not seen it before. It's possible I missed it, but I think I'd have caught it
Before, I had not seen a way to treat folders as devices; now, using the Connect/Share button, it looks as if they've improved the polling features on connected storage quite a bit. I still dislike what happens when I try to eject and reseat the card on my Honeycomb device (an Asus Transformer; the card has s tendency to wind up across the room because the microsd slot is aggressively springloaded) but I did just did a "connect/share" command on a mounted microsd card and a lot of the commands that formerly worked only with devices are available now for the card as well.
There is (or used to be) one gotcha with write to folder, and you should check your preferences in Calibre on this: you want to be sure you aren't writing .OPF files to to your folder if you use a reader like Fbreader.
When I first started batching files for the Asus, I was pushing the OPF as well as the EPUB files and fbreader, at least, was thinking it could read the OPFs.
Thank you very much for asking the quesiton - I wouldn't have looked at this again without it!
Windows sort of supports file management on the device, but between Google and Microsoft, there's no accurate representation of the current state of what's on the device.
The problem is much worse on the Windows side. I just ran through some tests to document what I see on the Asus device. Next up, I want to look at whether I can fix the filesystem mount on the microsd card - on the microsd, right now, the Asus mounts it not at
/sdcard
but at /Removable/MicroSD
I think that the following problems also exist on the internal storage, but have only done the process working with files and folders on the microsd card:
connect to your computer
browse to the MicroSD folder on the MTP display
from an android file browser, delete a file.
from your computer, browse back to your device.
Look! the file's still displayed to your computer (no directory refresh from android.)
Using Windows, create a folder on the 'droid device. Wow, have you ever seen anything that slow? And that's just the beginning.
Delete a file or folder from within Android, as you might well during your day, using file browsers on the device to make and remove objects. Look, Windows still sees the objects there!
Copying the nonexistent file or folder does not generates an error that Windows knows enough about to tell you. This is bad.
The folder issue is even worse than the file issue: a folder that's been deleted in Android is still displayed in Windows. When you copy that object out Windows will create a new, empty folder with the name of the (actually deleted) folder from Android.
Remember, when you checked that folder in Windows to be sure you had your data, it was still full of files. So you get a folder with the right name created but there's nothing in it. And there's no warning that an error occured.
Anyone still want to try backing up their Honeycomb device with windows?
Next, reboot your device.
If you leave your USB connected, you'll notice something very interesting: the thing doesn't even signal to windows that it's back.
Disconnect and reconnect USB.
Your device reappears.
That folder you deleted in Android before you restarted? Windows still thinks it's there even after an Android restart. You have to reboot Windows before it gets an accurate view of what Android knows is and is not around.
I suspect that that failure to notify windows that it's back and Windows not understanding that the file system have changed are related - there's a device arrival event that's only coming in over USB when the cable is pulled, not when power is restored with the cable connected.
Windows does see the device go away, at least.
The only way to get a re-poll of what's actually on the Android device is to reboot your computer.
It's possible that the seemingly useless Windows utilities that Asus bundles with the TF are actually there to solve this problem - they can force a re-poll and get an accurate view of what's on your device. They looked like junkware, so I uninstalled them, though
There are issues the other way as well, but they are less major:
from your computer, delete a file.
That file you deleted? Look, Android's gui still shows it's there. (the OS does know it's there, as you can confirm if you're also shelled in and do an ls) The gui won't update until you browse out of and back to the folder with the changing files.
From your computer, copy in a file. Look, android hasn't displayed it yet. Again, it is there, as ls confirms, but you won't see it until you refresh the display.
