Re: Can't delete file on device
Re: Can't delete file on device
- Subject: Re: Can't delete file on device
- From: Kyle Sluder <email@hidden>
- Date: Tue, 27 Mar 2012 14:29:41 -0700
On Mar 27, 2012, at 2:23 PM, Rick Mann wrote:
>
> On Mar 27, 2012, at 14:16 , Conrad Shultz wrote:
>
>> As David already pointed out you should probably be using file URLs.
>
> I made that change, and it behaves the same way. Even so, I don't see why that particular difference would allow it to work on the sim and not on the device.
>
>> There are a couple other issues:
>>
>> 1) You shouldn't handle errors by testing (err != nil). This might work
>> (since you initialized err to nil) assuming that removeItemAtURL: isn't
>> fiddling with err anyway, but it's not guaranteed. The preferred
>> approach is to test the return value of removeItemAtURL: (it returns
>> BOOL for a reason!) and examine err iff the method returns NO.
>
> Okay, I made that change, but it seems blatantly incorrect to create an error return if it is also going to return true.
Despite the impoliteness, the documentation used to explicitly warn that this was possible. The contract is "return value indicates success; if successful, *error is meaningless."
Nowadays with ARC, you can't trash *error without breaking ARC's rules.
>
>> 2) Less likely, but still reasonably plausible since you are working
>> with cache files (which I imagine have other clearance mechanisms), is
>> that you are encountering a race condition. It's possible that another
>> thread removed the file in the intervening time between your
>> fileExistsAtPath: and removeItemAtURL: calls. This is a major reason
>> why it's usually not useful to to ask "can I delete a file?" but rather
>> to try "delete the file!" and handle any errors appropriately.
>
> A race is possible, although I think unlikely (the call to the method that does the deletion is serialized on the main queue, although I suppose it's possible two operations are getting queued for the same file). In any case, I wasn't checking for it first, and then deleting it. I was checking for it only as a sanity check once I started seeing the problem. I was just deleting it and handling the error.
The more unlikely you think a race condition is, the more likely you are going to hit it at a very bad time.
Don't play around with race conditions. This is a fairly canonical example of a filesystem race.
--Kyle Sluder
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden