Referring to file by Alias ^or^ path
Referring to file by Alias ^or^ path
- Subject: Referring to file by Alias ^or^ path
- From: Bill Monk <email@hidden>
- Date: Wed, 03 Jun 2009 19:26:58 -0500
On Jun 1, 2009, at 6:59 PM, email@hidden wrote:
The following is a category on NSData which has two methods, one for
converting a path to an alias, and its vice versa. I've cobbled it
together from various sources over time.
Couple of points...
Given that your category depends on FSNewAliasFromPath, which is 10.5-
only, both blocks of
#if MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_4
Size size = GetAliasSize(aliasHandle) ;
#else
Size size = aliasHeader.aliasSize ;
#endif
can be dispensed with. Or else, FSNewAliasFromPath should be
conditionalized, since, as written, *it* will crash on 10.4 before the
GetAliasSize/AliasHeader.aliasSize code is reached.
AliasPtr aliasPtr = *aliasHandle ;
data = [NSData dataWithBytes:aliasPtr
length:size] ;
Might just as well say:
data = [NSData dataWithBytes:*aliasHandle length:size] ;
AliasRecord aliasHeader = *((AliasPtr)[self bytes]) ;
#if MAC_OS_X_VERSION_MIN_REQUIRED >= MAC_OS_X_VERSION_10_4
AliasPtr ap = &aliasHeader ;
AliasHandle ah = &ap ;
That sort of machination used to be known as "creating a fake handle"
- as distinguished from a "real" Handle, a pointer to a pointer to
relocatable block allocated by the Memory Manager . Doing that would
cause various havoc and crashes. You can get away with it now because
NewHandle ends up as a malloc call, and memory blocks are no longer
relocatable. Still, it just looks wrong to my eye. Worse, in recent
memory, fake handles could still cause trouble in OS X in certain
circumstances. (When I tried to google it, I found my own post from
2005: http://www.cocoabuilder.com/archive/message/cocoa/2005/8/16/144407)
But anyway, easier to sidestep it with GetAliasSizeFromPtr. A one-
liner replaces seven lines:
nBytesAliasRecord = GetAliasSizeFromPtr( (AliasPtr)[self bytes] );
osErr = FSCopyAliasInfo (
(AliasHandle)handle,
NULL,
NULL,
(CFStringRef*)&(path),
NULL,
NULL
) ;
// There may be a bug in the above function. If the
alias is to
// that of a nonexistent directory in the root, for
example,
// /Yousers
// Then the path returned will begin with two slashes.
// To work around that,
if ([path hasPrefix:@"//"]) {
path = [path substringFromIndex:1] ;
Interesting bug. I tried for a bit to see if it was reproducible in
10.4, but without FSNewAliasFromPath available it's down to
FSMakeFSSpec/NewAliasMinimal and, well, just couldn't make myself care
enough to mess with it much...
// The full path returned by FSRefMakePath will NOT
have a trailing slash UNLESS
// the path is the root, i.e. @"/". In that case
it will. Thus, in order to return
// a standard result to which "/Filename.ext"
should be appended, we remove that:
if ([path length] == 1)
path = @"" ;
How come? If the caller is correctly using
stringByAppendingPathComponent:, and not stringByAppendingString",
this shouldn't be a problem. The correct path for the root is @"/" and
I'd think needing to return anything else here implies a problem
elsewhere.
NSLog(@"*** Tests which should fail ***") ; ...
...
...
TestPath(@"/") ;
That test only fails because you force it to fail, by taking steps to
return @"" for the root. AliasManager returns the correct path; I'd
rather see it return that, and let callers either use
stringByAppendingPathComponent, or let it be their problem if they
have special reasons for not using it. But maybe that's just me...
_______________________________________________
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