Mac aliases bug
by James Urquhart · in Torque Game Engine · 09/03/2005 (2:52 pm) · 2 replies
There seems to be a problem with using aliases on Mac OSX in conjunction with torque.
Here is the situation:
I have built my .app and couldn't be bothered to move it into the example folder (sidenote: if anyone knows how to properly get xcode to move the built file there, easily allowing debugging, please tell me).
I decided to make some aliases in the terminal, using the ln command, like so :
example folder/main.cs -> directory with app in/main.cs
example folder/common -> directory with app in/common
example folder/starter.fps -> directory with app in/starter.fps
etc...
Upon loading torque, i was mystified as it suddenly quit without warning. However, upon closer inspection, it appears that the main.cs loaded, whilst torque couldn't find the directory's - very odd considering the equivalent "symbolic links" on linux work fine.
I have tracked the problem down to macCarbFileio.cc, in the Platform::isDirectory function. This function uses "PBGetCatInfoSync" to get the file info from OSX, but it seems it doesn't like aliases.
But wait now... the Platform::isFile function is almost identical, and the main.cs passed the test fine, and to top it all off, even loaded fine!
Unfortunately, i have not been able to find a solution to this problem. I've been going round in circles on the apple developer site trying to find any useful information or alternate functions i can use.
If anyone has any insight, please throw it my way :)
Here is the situation:
I have built my .app and couldn't be bothered to move it into the example folder (sidenote: if anyone knows how to properly get xcode to move the built file there, easily allowing debugging, please tell me).
I decided to make some aliases in the terminal, using the ln command, like so :
example folder/main.cs -> directory with app in/main.cs
example folder/common -> directory with app in/common
example folder/starter.fps -> directory with app in/starter.fps
etc...
Upon loading torque, i was mystified as it suddenly quit without warning. However, upon closer inspection, it appears that the main.cs loaded, whilst torque couldn't find the directory's - very odd considering the equivalent "symbolic links" on linux work fine.
I have tracked the problem down to macCarbFileio.cc, in the Platform::isDirectory function. This function uses "PBGetCatInfoSync" to get the file info from OSX, but it seems it doesn't like aliases.
But wait now... the Platform::isFile function is almost identical, and the main.cs passed the test fine, and to top it all off, even loaded fine!
Unfortunately, i have not been able to find a solution to this problem. I've been going round in circles on the apple developer site trying to find any useful information or alternate functions i can use.
If anyone has any insight, please throw it my way :)
About the author
#2
1.4 will see a rewrite of most of that stuff, pretty much in the way you describe.
I think some carbon calls have to be retained to deal correctly with unicode file names, and with the application bundle, but otherwise, the mac file handling stuff can and should be basically the same as the unix file handling stuff.
In OSX, there are several types of things you can call an Alias. There are the symbolic links that you describe above, made with 'ln -s', there are hard links, which involve too many caveats to discuss here, and should be avoided when possible, and then there are the old HFS alias files.
Some early versions of OSX occasionally had problems dealing with symbolic links. Applications that use older file handling methods will have these problems - symbolic links will look like regular files.
The unix layer has problems dealing with HFS alias files - the shell sees them only as regular files.
The best solution seems to be to use symbolic links, and the newer CFUrl based OSX calls in conjunction with the good old unix file handling routines.
09/04/2005 (3:17 pm)
Yeah, that stuff was in need of some love.1.4 will see a rewrite of most of that stuff, pretty much in the way you describe.
I think some carbon calls have to be retained to deal correctly with unicode file names, and with the application bundle, but otherwise, the mac file handling stuff can and should be basically the same as the unix file handling stuff.
In OSX, there are several types of things you can call an Alias. There are the symbolic links that you describe above, made with 'ln -s', there are hard links, which involve too many caveats to discuss here, and should be avoided when possible, and then there are the old HFS alias files.
Some early versions of OSX occasionally had problems dealing with symbolic links. Applications that use older file handling methods will have these problems - symbolic links will look like regular files.
The unix layer has problems dealing with HFS alias files - the shell sees them only as regular files.
The best solution seems to be to use symbolic links, and the newer CFUrl based OSX calls in conjunction with the good old unix file handling routines.
Associate James Urquhart
I ended up replacing alot of the code in macCarbFileio.cc with the equivalent functions in the unix platform code. I had to replace almost everything that used those crappy Carbon functions, which took a bit of time and effort.
This had the unintentional side-effect of making the alias files work - which i found very odd, since i expected that i'd have the same problem with the unix code.
Safe to say, i got the alias files to work *and* as a bonus, i got torque to use the current working directory in debug builds. But i'm left with the feeling that torque's mac code is being seriously neglected.