[sigil]

This is a system programming / kernel level issue.

I'm doing some hardware development on Mac OS X. When I plug the USB device in question in, I get a message box like this: "Disk Insertion: The disk you inserted was not readable by the computer" with two options, Ignore and Eject. If I choose ignore, the USB device can be accessed via the block special device /dev/disk1. However, /dev/disk1 cannot be opened for writing, even as root: the open(2) call always fails with EACCESS.

A "diskutil info /dev/disk1" reports "Read Only: Yes." Could this be the issue? How does Mac OS decide to set this flag?

FYI, a userspace program that interacts with this device file has so far been ported successfully to Windows, Linux, and FreeBSD. There's no read-only toggle switch on the device itself.

Thanks in advance for any info you may have.

[numero]

I've had some experience in the past year at my company with USB and OS X. My experience has been that Apple follows the spec. very closely. Windows allows for a lot of slop that doesn't get by on the Mac.

Try your device on a 10.4.11 machine (note: Not 10.4.10 on an Intel machine. We discovered a bug.) 10.4 was more forgiving than 10.5. If you find that you can work under 10.4 then start looking in your firmware for something that you thought was good enough, but not quite 100%.

If you have an ADC ticket available then try talking with the guys in the USB/Firewire group. They can probably get some logs from you and tell you what flag you are setting/clearing to give you this problem.

[sigil]

numero - thanks for the advice. This has been our experience as well, that 10.3 and 10.4 had more complete (or more forgiving) support for our mass storage device. Under 10.3 and 10.4 we can actually read and write to the USB block device, but the F_NOCACHE fcntl errors out, and unfortunately we depend on unbuffered I/O.

Have you tried your device under linux or a BSD? I find it a bit surprising that, of the lot, Apple's mass storage drivers would be the strictest in terms of enforcing the spec.

[numero]

Linux for us had the same issue as the Mac did.

A little more about our situation. We are using this USB device to communicate with our equipment. Our equipment has IR ports on them. This USB device has an IR transceiver on it. The data from our equipment is received by the USB device and its firmware writes the data to the mass storage of the USB device. The Mac sees this device as a mass storage device. Our problem came because the USB device has a split personality. As far as the Mac knows it is a simple flash drive, but we are changing the file system from the outside. I believe that OS X is caching the file system and never goes back for another look since there haven't been any read/write requests come through the OS. As a result we were not getting notice of the updates that our firmware was writing to the file system. The solution was to read the device through the /dev file. This required reading the FAT file system by hand.

Are you doing something similar with changing the file system through direct access? If so, then I would think that your F_NOCACHE flag won't do any good since that does affect how directory/file info is cached.

You might want to poke around with researching the unified buffer cache. I don't remember the details now, but when I was working on this problem is shed some light on the behavior I was seeing.

Feel free to contact me at my .mac account. Same name as the one I use here.

Doug

[sigil]

To avoid kernel buffering of reads and writes, can you use the /dev/rdiskN block device file instead of /dev/diskN? Someone on darwin-drivers suggested that to me, and in our case it made the difference.