Re: NSDocument and symlinks

[Fred Kiefer]

Hi Rob,

first of all, you should have put this report into Savannah. This would 
make it easier to keep track of replies. Not the lack of them :-)

Rob Burns wrote:
> On 2005-04-29 17:46:37 +0700 Rob Burns <foobix@comcast.net> wrote:
>
> > I found recently that when using Gworkspace to open a file which was 
> > actually a symlink to a file, the correct app would come to the 
> > foreground, but then display an error message stating that the "file" 
> > (actually the path to the symlink) couldn't be opened. These were 
> > NSDocument based applications. TextEdit had no problems opening 
> > symlinks from GWorkspace. So, I took this bit of code from TextEdit 
> > and put it at the beginning of  the openDocumentWithContentsOfFile: 
> > display:   method of NSDocumentController.
> >
> >      NSString *resolvedSymlinks = [fileName 
> > stringByResolvingSymlinksInPath];
> >      if ([resolvedSymlinks length] > 0)
> >        {
> >          NSString *standardized = [resolvedSymlinks 
> > stringByStandardizingPath];
> >          fileName = [standardized length] ? standardized : 
> > resolvedSymlinks;
> >        }
> >
> > It all seemed to work ok after that. I specify opening from 
> > GWorkspace, because when using the Backbone projects' 'open' tool, all 
> > apps including NSDocument based apps worked fine (without the small 
> > fix). I'm not sure what the results are with the 'open' tool that 
> > comes with GNUstep.
> >
> > Thanks
> > Rob
>
> Sorry to reply to my own message. After using this for a few days I've 
> found that it allows NSDocument based apps to open links to files, but 
> it also allows NSDocument based apps to open links to files multiple 
> times (in the same application). If its a reasonable fix, its not yet 
> complete.

Yes, this would fail, as now the document is registered with the 
resolved file name. You either need to resolve the symbolig link before 
you do the documentForFileName: lookup or later in NSDocument 
readFromFile:ofType:. But first you should check the comment in 
NSDocument loadFileWrapperRepresentation:ofType:. There somebody stated 
before the exception gets raised:

/*
     * This even happens on a symlink.  May want to use
     * -stringByResolvingAllSymlinksInPath somewhere, but Apple doesn't.
     */

If this is still true, we should stick with the current behaviour. 
Perhaps somebody with an Apple computer and to much time could try and 
find out at which point Cocoa resolves symbolic links, if they get 
resolved a t all.

Cheers
Fred