bugGNUstep - Bugs: bug #32564, Cannot start applications with the...

 
 

You are not allowed to post comments on this tracker with your current authentication level.

bug #32564: Cannot start applications with the symbolic link created in the Tools directory

Submitted by:  Wolfgang Lux <wlux>
Submitted on:  Mon 21 Feb 2011 09:53:54 PM UTC  
 
Category:  Base/Foundation Severity:  3 - Normal
Item Group:  Bug Status:  Fixed
Privacy:  Public Assigned to:  None
Open/Closed:  Closed

Sat 05 Mar 2011 07:34:10 PM UTC, comment #5: 

Yes, the fix works for me, too.

Thanks

Wolfgang Lux <wlux>
Sat 05 Mar 2011 04:38:48 PM UTC, comment #4: 

OK ... think I understand now ... does the latest change fix it?
It seemed to work for me with PROCFS_EXE_LINK disabled.

Richard Frith-Macdonald <CaS>
Project Member
Sat 05 Mar 2011 04:09:56 PM UTC, comment #3: 

Reopened

Richard Frith-Macdonald <CaS>
Project Member
Sat 05 Mar 2011 04:06:40 PM UTC, comment #2: 

I'm sorry, but your changes did not fix the problem. (How do I reopen this bug?)

I guess, my problem description wasn't clear enough, so I'll try again. When one starts an application, say Ink, through the link in the Tools directory, the absolute executable path computed by NSBundle is /usr/GNUstep/Local/Tools/Ink. Hence, NSBundle tries to open the main bundle of that application in /usr/GNUstep/Local/Tools where apparently it doesn't exist. To get things right, the NSBundle code at some point must resolve the symlinks in the path to the executable so that it will look up the bundle in the directory /usr/GNUstep/Local/Applications/Ink.app. Until David's change, this implicitly happened -stringByStandardizingPath, but now we'll have to do that explicitly at some point.

I think this problem doesn't show up under Linux because GSPrivateExecutablePath() reads the executable path from the process file system and the kernel apparently resolves the symbolic link. Eventually, you can test things under Linux by temporarily commenting out the code following #ifdef PROCFS_EXE_LINK in GSPrivateExecutablePath()

Wolfgang Lux <wlux>
Sat 05 Mar 2011 03:12:57 PM UTC, comment #1: 

I modified the bundle code to try to create absolute paths ... hope this works

Richard Frith-Macdonald <CaS>
Project Member
Mon 21 Feb 2011 09:53:54 PM UTC, original submission:  

Starting an application by entering the name of the symbolic link on the command line does not work anymore. Applications started in that way will fail with an error saying that they cannot find their main nib file. Starting the application with openapp or by entering the full path of the main executable file still works.

The problem can be observed on every platform where NSBundle's GSPrivateExecutablePath returns a relative path when the application was started without entering the full path of the application's main executable, which seems to be every platform out there except Linux, and was introduced in r32109 when NSString -stringByStandardizingPath stopped resolving symbolic links. For instance, the path of an application's main bundle does not resolve to the application directory but to the tools directory containing the symbolic link instead.

Simply changing all calls to -stringByStandardizingPath into -stringByResolvingSymbolicLinksInPath does not work either, apparently because the latter method converts all relative paths into absolute paths by prepending the current directory. (BTW, this behavior seems to be incompatible with OS X as well; I tried that for a few simple cases including [@"." stringByResolvingSymbolicLinksInPath] and [@".." stringByResolvingSymbolicLinksInPath] and OS X doesn't seem to convert relative paths into absolute paths.)

Wolfgang Lux <wlux>

 

No files currently attached

 

Depends on the following items: None found

Items that depend on this one: None found

 

Carbon-Copy List
  • -email is unavailable- added by CaS (Posted a comment)
  • -email is unavailable- added by wlux (Submitted the item)
  •  

    Do you think this task is very important?
    If so, you can add your encouragement to it.
    This task has 0 encouragements so far.

    Only logged-in users can vote.

     

     

     

    Follow 7 latest changes.

    Date Changed by Updated Field Previous Value => Replaced by
    2011-03-06 CaS Open/ClosedIn Test => Closed
    2011-03-05 CaS StatusIn Progress => Fixed
        Open/ClosedOpen => In Test
    2011-03-05 CaS StatusFixed => In Progress
        Open/ClosedIn Test => Open
    2011-03-05 CaS StatusNone => Fixed
        Open/ClosedOpen => In Test

    Back to the top


    Powered by Savane 3.5