If you do not use the A: drive anymore (cannot imagine anybody still using it but I have been proven to be wrong before), you could try to disable it in the PC's BIOS settings, and/or via the device manager of your (Windows) OS.

Drive A: (and B: ) are hardcoded/hardwired build-in left-over relics of non-mobile devices, but still valid when not de-activated. So searches over all drives will also include A:, B:, C:, etc. I do not think calibre should solve this.

For WinXP, there existed a tweak utility to let windows "know" not to use drive A, B by unchecking some check-box. Did a quick search for something similar on my Win7, but no luck (have no A/B floppy drive anyway).

Further, as windows allows renaming drive indications, drive A: might actually map to some exsisting external USB-drive. Another reason not to solve this in calibre.

OS level? Don't think so. I'm using XP and Calibre is polling the A: drive constantly, not the Kobo. I don't know why and shutting off the A: drive because of Calibre doesn't seem to be the right direction to me. As soon as I unmount the Kobo the polling stops. Something is in Calibre that's buggered.

OS level? Don't think so. I'm using XP and Calibre is polling the A: drive constantly, not the Kobo. I don't know why and shutting off the A: drive because of Calibre doesn't seem to be the right direction to me. As soon as I unmount the Kobo the polling stops. Something is in Calibre that's buggered.

When calibre detects the kobo, it asks windows for the list of drives so it can mount the kobo's memory. This causes windows (not calibre) to poll A:. If the kobo is not completely detected (busted memory or an unknown drive string), the process repeats in a bit.

If you have a "fix" for this "bug", I am sure that Kovid would love to have it. He said as much in the bug report that I pointed toward.

I don't anything about the phone and how it interfaces. If the issue is writing to an SD card, can't that writing be done to one of those little USB drives that mounts an SD card?
Then the card could be restored to the phone.

When calibre detects the kobo, it asks windows for the list of drives so it can mount the kobo's memory. This causes windows (not calibre) to poll A:. If the kobo is not completely detected (busted memory or an unknown drive string), the process repeats in a bit.

Can you explain what you mean by "not completely detected"? In my naivety, I would have thought that a device would either be detected or not. What does "not completely detected" actually mean?

Can you explain what you mean by "not completely detected"? In my naivety, I would have thought that a device would either be detected or not. What does "not completely detected" actually mean?

It means that some device connected to the computer has USB IDs that calibre recognizes, but that either no disk drive known by calibre to be associated with the device can be found or the disk drive cannot be written. This situation can arise because the device is non-standard, is new but reuses a previous USB ID, or has firmware changes that calibre doesn't know about. It can also happen if some device is presenting bogus USB IDs.

It means that some device connected to the computer has USB IDs that calibre recognizes, but that either no disk drive known by calibre to be associated with the device can be found or the disk drive cannot be written. This situation can arise because the device is non-standard, is new but reuses a previous USB ID, or has firmware changes that calibre doesn't know about. It can also happen if some device is presenting bogus USB IDs.

Thanks! I appreciate the explanation. Presumably the reason for the retry is in case the device simply hasn't finished initialising the USB connection, or something like that?

Thanks! I appreciate the explanation. Presumably the reason for the retry is in case the device simply hasn't finished initialising the USB connection, or something like that?

That is one reason. Another is that the device might actually have been changed between scans.

I suppose we could detect that a given USB ID has failed N times in N tries and stop checking it until it disappears for a complete cycle (or something like that). My problem is that I have no motivation at all to take on this task, having neither a floppy drive nor a device that isn't fully recognized.