Re: NSBundle -initWithPath: warning

[Richard Frith-Macdonald]

On 2005-04-01 05:13:57 +0100 Sheldon Gill <sheldon@westnet.net.au> wrote:

> > No ... but I can easily see what the problem is ... '//Local/Library'
> > looks like a windows UNC path where 'Local' is the host and 'Library' is
> > the share and the actual file is unspecified ... ie it would be a
> > relative path on windows.
>
> Absolute path on windows.

So I gathered after much trawling of the web ... I've updated isAbsolute to 
regard UNC style paths as absolute in all cases.

> > I've fixed NSString to know that it's an absolute path when running on
> > unix.
>
> IMHO this is a partial mis-diagnosis of the fault.
>
> Consider the code:
> ----<begin code> ----
>
> - (id) initWithPath: (NSString*)path
> {
>   [super init];
>
>   if (!path || [path length] == 0)
>     {
>       NSLog(@"No path specified for bundle");
>       [self dealloc];
>       return nil;
>     }
>   if ([path isAbsolutePath] == NO)
>     {
>       NSLog(@"WARNING: NSBundle -initWithPath: requires absolute path 
> names!");
>       path = [[[NSFileManager defaultManager] currentDirectoryPath]
>                stringByAppendingPathComponent: path];
>     }
>
>   /* Check if we were already initialized for this directory */
>
> -<snip>-
>
>   if (bundle_directory_readable(path) == NO)
>     {
>       NSDebugMLLog(@"NSBundle", @"Could not access path %@ for bundle", 
> path);
>       [self dealloc];
>       return nil;
>     }
>
> ---<end code>---
>
> Why is the code checking for an absolute path? It is superfluous and is 
> more 
> likely to cause problems than solve them.

I'm not sure about that ...  The NSBundle documentation says this should be 
a 'full pathname', so it looks like the GNUstep implementation is checking 
and then trying to be a bit more tolerant than the documentation suggests.

> Later on, it checks that the bundle directory is readable. Why?

Because the NSBundle documentation specifies that the intiialiser must 
return nil if the directory 'doesn't exist or the user doesn't have access 
to it'

> Surely the better option is to simply make the open calls and handle 
> failures 
> properly. That much has to be done anyway. Why complicate matters by doing 
> checks that don't give us any real benefit?

I think they give us the benefit of making sure that the code is MacOS-X 
compatible.

> Consider 1: If the path isn't absolute it may still work in some cases. In 
> the cases it doesn't work, it'll fail to find the file because the path is 
> incorrect. Just like it'd fail if the path was otherwise incorrect.

Yep ... so the current code will work in more cases than if the check and 
conversion of relative to absolute path was omitted.  I think that's a 
(minor) win for the code as it is.  However, I think it's also arguable that 
we should be less tolerant and fail in all cases where the supplied path is 
relative ... but only if that's the actual MacOS-X behavior.

> Consider 2: if the bundle directory is unreadable, it'll fail when we try 
> to 
> read it. Try to read it and handle not being able to.

Yep ... so it will fail in a place other than that in which it is documented 
to fail ... so code written by reference to the documentation (eg written 
for MacOS-X) and testing the results of the init method will go wrong.

Generally, we should try to ensure that methods conform to the letter of the 
Apple documentation AND match the behavior in MacOS-X ... though 
occasionally the two actually conflict.