Re: pread and EACCES error?
Re: pread and EACCES error?
- Subject: Re: pread and EACCES error?
- From: Brian Bergstrand <email@hidden>
- Date: Thu, 21 May 2009 22:25:14 +0300
On May 21, 2009, at 9:19 PM, Terry Lambert wrote:
On May 21, 2009, at 1:26 AM, Brian Bergstrand wrote:
Hi Terry,
The code is not multi-threaded. It's a fairly simple command line
tool. I don't have a custom KEXT installed either.
I do a bunch of preflight to get disk sizes, make sure the devices
are not mounted, etc. I then open a read handle on the source
device and a read-write handle on the target device. The tool then
enters a loop and just preads from the source and pwrites to the
target. All on one thread. The tool is linked against
CoreFoundation and libSystem - nothing else.
If I have a read handle open on the device and something causes
diskarb to attempt to remount any volumes on the device could that
cause the problem? I don't see how, because I can open a read
handle on a disk containing mounted volumes or on the mounted
volumes themselves (just not a write handle).
A forced revocation of the descriptor could result in an EBADF, but
not an EACCES.
Also, in general, you should be prepared for any error back from any
system call, not just the ones on the man pages. People write all
sorts of plugins and there are all sorts of third party drivers for
Firewire and thumb drives and other devices, that the man page error
numbers merely document what the code paths would return without
third party software being involved.
Yes, I understand that. And the code does handle any error, but it is
an error and therefore the copy is aborted. If I knew why the error
occurred I might be able to handle it a different way.
3rd party software is likely not the cause. This error is seen running
as root on the 10.5.6 DDK environment DVD and it's been seen running
as root on a stock 10.5.7 normal install. It's not reproducible at
will, so it's hard to pin anything down. All I have are logs.
Also the offset where the error occurs is a native disk block boundary
(although if it wasn't I should get back EIO).
Thanks for your help.
-- Terry
Thanks.
On May 21, 2009, at 10:32 AM, Terry Lambert wrote:
There is nothing directly in the normal code path that does kauth
checks after the open is successful. So it's your driver or your
code. Is you code multithreaded? If so, does it serialize the close?
-- Terry
On May 20, 2009, at 2:55 AM, Brian Bergstrand wrote:
Hi all, I'm seeing a weird error from pread in the following setup:
Copying from a 300GB PATA drive connected via USB to another
300GB ATA drive connected via Firewire using the raw char devices
for each. After copying about 37GB of data, pread fails on the
source USB drive with EACCES (13). According to the man page,
this is not a valid error return (although the man page may be
out of date).
The copy is done in DKIOCGETMAXBLOCKCOUNTREAD chunks (128KB for
ATA).
So where is the EACCES coming from? The IOKit block drivers? And
what does it mean in this situation?
Mac OS X 10.5.7 (Darwin 9.7) on Intel.
Thanks for any help?_______________________________________________
Brian Bergstrand
<http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2
Brian Bergstrand
<http://www.bergstrand.org/brian/> PGP Key ID: 0xB6C7B6A2
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Darwin-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden