Thank you all for your ideas. With various suggestions, I found a variation of the CDRomSample code that seems to work well. The sample does reads on the BSN Name of the device root (i.e. /dev/rdisk#). I have found that if I dig a little deeper into the IORegistry for the device (i.e. /dev/rdisk#s0), the code works.
Rich
Actually, I think the flag he needs is O_DIRECT upon open(), however I don't see than in the man page on Mac OS.
Eric
On Mar 17, 2010, at 12:08 PM, Kevin Elliott wrote:
> F_NOCACHE tells the filesystem that it shouldn't cache the data being read, but it does not mean that it will read the data from disk. It's intended to be used as a performance optimization to prevent filling the cache with data that will only be used once. If using F_NOCACHE meant eating the penalty of an uncached read, I suspect many of it's current users would be very upset.
>
> The only way I know of to perform an uncached read is to open the rdev node and read from it at a block level. Obviously, that will involve significantly more work, so perhaps someone else will suggest a technique I'm unaware of.
>
> -Kevin
>
>
>
>> I know it (fread) is not going over the USB bus
because I ran a CATC trace on it.
>>
>> The Open/Read/Close code I am using is similar to the Apple sample CDRomSample. It is not that this does not work, it is that it has side effects with the device I am working with that causes other problems.
>>
>> Rich
>>
>> On Mar 17, 2010, at 7:09 AM, Dave Camp wrote:
>>
>>> On Mar 17, 2010, at 6:49 AM, colors wrote:
>>>
>>>> I am running into a problem with anti-virus software. I need to be able to read a file from a USB CD and I need the read to actually go over the USB bus.
>>>>
>>>> I have been just doing fopen, fread, fclose, etc. and that all works; although, I do set the file to F_NOCACHE with fcntl to make sure that I read the file from the device and not a read cache. I have also tried fpurge.
>>>>
>>>> Unfortunately,
the AV software is getting in the way. fread completes happily and gets the correct bytes, but the bytes did not travel across the USB bus. It appears that the AV SW is doing its own cacheing and feeding me the bytes I ask for.
>>>
>>> How do you know it's not going over the USB bus?
>>>
>>>> I have also tried to use open, read, close. They do get the data from across the bus, but they also have a side effect of the closing the IOKit service, which makes it look like the device was pulled out of the USB port. Read also reports an I/O Error, even though the bytes are traveling across the bus.
>>>
>>> Open, read and close are used by all sorts of software. If those did not work across the board with AV software installed I would expect the machine to be almost unusable.
>>>
>>>> I have also considered making SCSI Read calls or
USB Read calls, but it looks like I will only be allowed to do this if I make my own kext.
>>>
>>> Were you to operate at the device level, you would be able to read physical blocks from the device, but I don't know how you would correlate those with the logical blocks of any given file. Thats what the filesystem does...
>>>
>>>> Does anyone have any thoughts about 1) what the AV SW is doing?, and 2) how to get around what it is doing?
>>>>
>>>> BTY, I know of at least three AV products that cause this problem.
>>>
>>> Posting some code showing how you are reading files might help.
>>>
>>> Are your problems limited to USB CD drives? Does your code work when the CD is in the internal drive?
>>>
>>> Dave
>>>
>>
>>
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Filesystem-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden