mac problem Right, my emac g4 is being a twat. For no apparent it has decided not to play or rip cds which people have burned from another computer. I havent tried burning my own since the problem though. It will allow me to play and rip cds which ive already played, but nothing new. Its got nothing to do with updates as my house mate's mac will play and rip the same cds fine, and he hasnt updated his mac for ages. It will play the cds or rip them for a little bit then comes up with error -36. Mac site brought up shit. Does anyone have any idea what the crack is? Oh and it still plays dvds.
this from macforums......... It's quite a general error that means OSX is having trouble reading and writing to the drive. Open Disk Utility and try repairing the external drive. If that doesn't help, then would reformatting the drive be an option if it comes to that? or (totally incomprehensible to me)........ Usually ioErr (-36) means something has gone deeply wrong at the lowest levels. Here's what the actual header file says if you have Apple's Carbon SDK: ioErr = -36, /*I/O error (bummers)*/ That is, generally speaking, application programs can't recover from this - it would usually mean the hard drive is going bad. By comparison paramErr (-50) means you passed something illegal to the function. Well it turns out that if you pass a block of memory to FSWriteFork and part of that memory is not mapped (that is, trying to access that memory to do the disk write generates a segfault) then you get ioErr back, not paramErr. That tip led us to realize that what we really had was (blushes) bad endian-swapping code that (on little-endian Macs only) generated bogus pointers. Depending on luck and the stars, that bogus memory might be mapped (thus writing junk into the file) or unmapped (generating the -36 error), hence the unreliable behavior. In hindsight this isn't surprising, once you realize that Mac Carbon file calls are written on top of BSD file manager calls. I don't know the actual implementation of FSWriteFork, but what if it uses BSD's "write"? Well, that can return EFAULT if you pass in unmapped memory.
