Error transferring command; errno 0 null

Problem

Cannot write more than 100-ish files to the drive in a row, and drive loses connection. This is only happening on new drives that we are using, and cannot be reproduced on all drives. I have tried reformatting the drive and it does not help.

Expected behavior

To be able to continuously write files to the drive

Actual behavior

receive error when attempting to write the drive, and drive loses connection

Stacktrace of Excpetion

D/ClusterChain: Init a cluster chain, reading from FAT D/ClusterChain: Finished init of a cluster chain D/ClusterChain: grow chain D/FsInfoStructure: writing to device I/FAT: allocating clusters finished E/ScsiBlockDevice: Error transferring command; errno 0 null D/ScsiBlockDevice: Reset bulk-only mass storage W/ScsiBlockDevice: sending bulk only mass storage request D/ScsiBlockDevice: Trying to clear halt on both endpoints W/AndroidUsbCommunication: Clearing halt on endpoint UsbEndpoint[mAddress=130,mAttributes=2,mMaxPacketSize=512,mInterval=0] (direction 128) 2020-05-08 18:01:46.013 16002-16816/ W/AndroidUsbCommunication: Clearing halt on endpoint UsbEndpoint[mAddress=1,mAttributes=2,mMaxPacketSize=512,mInterval=0] (direction 0) E/ScsiBlockDevice: Error transferring command; errno 0 null D/ScsiBlockDevice: Trying to reset the device D/AndroidUsbCommunication: Performing native reset W/AndroidUsbCommunication: ioctl failed! errno 0 null W/AndroidUsbCommunication: USB device will likely require new discovery and permissions

I also see this when I run first aid on the drive following the issue:

/Backups/Nexus 6P/Camera/10H.jpg has too many clusters allocated (logical=0, physical=2195456)

Code where problem occurs

val buf = ByteArray(fileToWrite.chunkSize)
var count: Int
while (inputStream.read(buf).also { count = it } > 0) {
     outputStream.write(buf, 0, count)
}

[depau]

Relevant code, if you wanna give it a look: https://github.com/magnusja/libaums/blob/38d4a6b6f9e602f6148a5cc2234cd8c3382e86a3/libusbcommunication/src/main/java/me/jahnen/libaums/libusbcommunication/LibusbCommunication.kt#L81-L98

[depau]

Can the transfer be trapped at the failed write then made to wait 10 seconds before searching for the device and attempting to repeat last write and continue? If so, we could eliminate heat as a possible factor, even if we expect it to have to do that a few times to complete a burn process.

This has been tried, at least by me since many times I stepped around in the debugger while this issue was going on. No, waiting won’t do any good.

Can you please attach here the logcat including the part before the issue occurs? I’m expecting to see some attempted recovery steps.

Also if your device is rooted and you can provide the kernel log, that would help too.