Re: How determine if file is in Trash, given Path or Alias
Re: How determine if file is in Trash, given Path or Alias
- Subject: Re: How determine if file is in Trash, given Path or Alias
- From: Quincey Morris <email@hidden>
- Date: Mon, 1 Jun 2009 21:31:40 -0700
On Jun 1, 2009, at 14:53, Gwynne Raskind wrote:
On Jun 1, 2009, at 4:31 PM, Sean McBride wrote:
This is a nice trick, I wasn't aware of that function, thanks.
Perhaps a minor improvement (one call instead of two):
- (BOOL) isTrashedFileAtPath:(NSString*)path
{
Boolean inTrash = false;
const UInt8* utfPath = (UInt8*)[path UTF8String];
OSStatus err =
DetermineIfPathIsEnclosedByFolder(kOnAppropriateDisk,
kTrashFolderType, utfPath, false, &inTrash);
return (noErr == err) ? (true == inTrash) : NO;
}
Probably it does the same thing behind the scenes, but why not.
For the archives: 2 more problems:
a) use fileSystemRepresentation not UTF8String.
b) with GC, 'path' may be collected before
DetermineIfPathIsEnclosedByFolder() is finished with utfPath. So
best
to add a [path self] just before the 'return'.
This is a perfect example of why I would never use GC: That is the
most nonintuitive confusing behavior I have ever heard of. If I
crashed in the middle of DetermineIfPathIsEnclosedByFolder() for
that reason I would never guess that GC was responsible!
Sorry, I can't let this pass without comment.
First, I believe Sean is wrong about (b), although the documentation
is a little unclear. The description of [NSString UTF8String] says
that "the returned C string is automatically freed just as a returned
object would be released", which implies (to me) that the returned
pointer is to GC-controlled memory. In that case, the reference to the
block held in stack variable 'utfPath' keeps the memory alive until
DetermineIfPathIsEnclosedByFolder is called, and that function's
parameter variable (another stack reference to the block) keeps it
alive as long as the function needs. Because 'utfPath' is a separate
block of memory, once it has been created, the lifetime of 'path'
isn't relevant.
There would only be a problem if [NSString UTF8String] returned an
*interior* pointer to memory owned by 'path'. In that case, Sean's
statement would be correct -- the lifetime of 'path' might need to be
artificially extended. But the documentation does not really support
that interpretation.
This is in contrast to [NSData bytes], which really does return an
*interior* pointer to memory owned by the NSData object. Interior
pointers and GC are problematic. :)
Second, even if Sean is correct, I believe you'd be going too far by
refusing to use GC as a consequence. There are plenty of gotchas in
Cocoa generally, and this mailing list pretty much thrives on the
resultant confusion and noninutiveness. The context doesn't even seem
terribly non-intuitive to me -- if you use a method that returns a non-
object pointer to memory you didn't allocate (and there are only a
handful of such methods), then it seems fairly intuitive to ask
yourself what steps might be necessary to keep the memory alive (and
the answer may be "none necessary") -- regardless of whether you're
using GC or retain/release.
_______________________________________________
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