Re: Resolving alias
Re: Resolving alias
- Subject: Re: Resolving alias
- From: David Remahl <email@hidden>
- Date: Sat, 25 Jan 2003 05:25:43 +0100
Bayley,
Hmm...I was thinking...
Would it even be possible to do this in a backwards compatible way? I
mean, if one made a XXFSRef class (XX indicating that it doesn't have
to be Apple sanctioned) that is a subclass of NSString, which really
just forwards all string related method calls to the path of the file
which it represents...
The problem is NSString has methods to edit the string plus you can
only have an FSRef for an existing file.
Well, since the object creating an XXFSRef is generally aware of this
limitation, it can either work with exceptions, or check for nil. If
someone tries to create an XXFSRef to a non-existent file, then that is
a problem.
But NSStrings do not have methods for editing the string.
NSMutableString does. NSString has methods like these:
- (NSString *)stringByAppendingString:(NSString *)app;
The designer of XXFSRef would have to decide what to do with this API.
It should probably just return plain NSStrings, not subclasses of
XXFSRef.
You could handle this by checking if the file exists every time the
string changes then using an FSRef instead of a string until the
string was purposely changed but that's a lot of work an could lead to
problems depending what asusmptions the programmer makes.
Since NSStrings are immutable, with the exception for NSMutableString,
this is only a problem once if we make an XXMutableFSRef.
You also mention assumptions...That could be a problem, if some API
that expects an NSString does something like this:
// assume path exists, and is of kindOfClass, XXFSRef.
NSArray *subpaths = [[NSFileManager defaultManager]
directoryContentsAtPath:path];
// at this point the user moves the directory referenced by the XXFSRef
"path". path is still valid, but the NSString paths in subpaths are
invalid...
// doing something with subpaths causes problems...
There could also potentially be race conditions of various kinds...If
the file pointed to by an XXFSRef is moved suddenly, the XXFSRef won't
notice, or it will notice, and other objects in the process of doing
things like this:
int strlen = [xxfsref length];
for( i = 0; i < strlen; i++ )
unichar uc = [xxfsref characterAtIndex:i];
will fail horribly if the length of the file name changes while inside
of the loop (alright, this isn't the best of examples, but it should
illustrate the point).
The problem to begin with is a POSIX file path is being used as a file
primitive.
In a word: Yes...Unfortunately...The question is what the best we can
do of the situation is...Foundation/AppKit already have two somewhat
competing ways of specifying files and file locations: NSString (POSIX
paths) and NSURL's. Unfortunately, they both have the same drawbacks
when it comes to traditional Mac OS file behaviour.
My suggestion was to create a XXFSRef which could return an NSString
but did not implement NSString methods.
Yes, I understood that. But that method has many of the same problems,
since the XXFSRef is irreversibly transformed into an NSString when it
is passed to unknowing API such as Foundation or AppKit:
NSArray *subpaths = [[NSFileManager defaultManager]
directoryContentsAtPath:[xxfsref string]];
/ Regards, David Remahl
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.