Accessing a symbolically-linked class in r2007b

Hey all,

I'm running into a problem while trying to instantiate some classes, running r2007b. I have a central location where I store most of my completed projects and utilities. When I need to access one of these in a new project, rather than adding the central location to my path, I create a symbolic link to the needed application somewhere in the directory structure of the project I'm working on. This is intended to allow me to make bug-fixes in one location, which propagate to all instances where the application is used. This worked well for me until I tried to link to a class directory.

Using the standard 'ln -s' syntax in terminal, I created a link to the directory '@foo' in my central storage directory. I then verified that the link was valid by navigating to the directory of my current project, checking that '@foo' existed and was a symbolic link, and then double-clicking it to find myself back in the central storage directory. However, when I tried to instantiate the class with the command 'bar = foo', Matlab was unable to locate the class. I ensured that the root directory 'example_proj' was on the path, and 'example_proj/@foo' was not, with no change in the results. I then removed the symbolic link, and copied the class directly to the root directory. Matlab was then able to find the class. Does Matlab not allow the use of symbolically-linked classes in 2007b?

[Matt J]

What is the name of the link itself? Is it '@foo'?

[Jason]

Yeah. The link itself is named @foo. It links to the class directory ~/bar/classes/@foo. The link was created using the terminal command 'ln -s ~/bar/classes/@foo', where the working directory was my current project's folder. So, if I look at my current project's root directory, I can see a folder labelled @foo, which appears indistinguishable from the folder located at ~/bar/classes/@foo (aside from being a symbolic link)

[Jason]

My workaround actually revealed some surprising behaviour. I grouped the classes into categorical folders, and linked to the folders I needed (This is less than ideal. At this point, I may as well use addpath). Matlab is able to access the classes, but navigating within the working directory window reveals that Matlab is somehow finding the absolute path on the filesystem. My directory structure looks somewhat similar to the following:

project directory: ~/bat/current_project

directory containing classes: ~/bar/classes/foo_type_classes

Within the project directory, I have a symlink to the directory containing the classes. So, ~/bat/current_project/foo_type_classes.

The behaviour I expected when navigating through the symlink to a class is that my path would be something like ~/bat/current_project/foo_type_classes/@foo. The actual behaviour is that my path becomes ~/bar/classes/foo_type_classes/@foo. Obviously, Matlab does something different when accessing directories, compared to terminal or Nautilus. Interestingly, I think r2011b uses the same behaviour as terminal, although the license server is currently inaccessible, so I can't double-check.

[Jason]

One more interesting thing I've found. Using 'which('foo.m')' from my project's directory returns the path to foo.m, traversing the symbolic link. The path returned looks like ~/bat/current_project/foo_type_classes/@foo/foo.m. Changing the directory using cd(fileparts(which('foo.m'))) dumps me back into ~/bar/classes/foo_type_classes/@foo. These inconsistencies are making me wonder if maybe I'm relying on some kind of undocumented functionality.

Answer 1

[Daniel Shub]

Issues with symbolic links have been discussed before. In that question, Walter pointed out that MATLAB handles links in a POSIX compliant way, but that the POSIX behavior is not obvious.

[Jason]

Ah, I remember reading that discussion a few weeks ago, before I ran into this problem. I guess the meaning didn't stick without the context. Guess I'll stick with the workaround until I come up with something better.

Thanks.

[Walter Roberson]

I had forgotten that discussion!

[Daniel Shub]

I am not sure that it is really what is going on here, but it might be a start.