Files on path are inaccessible (sometimes)

I have an .m file called staverify.m (the path is 'C:\Matlab\spike\demo'). I also have 'C:\Matlab' and all of its subfolders in the search path. When my current folder is set to 'C:\Matlab\spike\"anything"', where "anything" is any one of the subfolders of \spike (even empty folders), then I can run staverify without a problem. If my current folder is set to any other folder, though, then I get this error:

??? Error using ==> load Unable to read file ..\data\verify_expected: No such file or directory.

Error in ==> staverify at 10 eval(strrep('load ../data/verify_expected','/',filesep));

The verify_expected file is the first file staverify calls and is, in fact, in '\spike\data', which is on the search path. If I run 'which verify_expected.mat', it finds the file immediately. I get similar errors for other files, often with compiled mex files not being found but their .m counterparts being found. This is crippling my ability to run any of my programs.

None of these files are in the toolbox folders; I saw how common that error was, and double-checked. I haven't made any changes to the toolbox folders at all, except for saving the search path.

Answer 1

[Walter Roberson]

When you specify a directory then (as far as I know), load() does not search along the search path, and instead assumes that the path is relative to the current directory if it is not an absolute path.

Answer 2

[Leah]

I get this error sometimes when I am working on a server and have drives mapped differently. I don't think this is your issue since C: is probably your local drive.

Try adding the file extension or using addpath

http://www.mathworks.com/help/techdoc/ref/addpath.html

[Andrew Fooden]

Ok, this might be a rather large problem. When I use addpath and savepath, or even the 'set path' dialogue box, it makes changes to pathdef.m, but when I reload Matlab, those changes aren't implemented. The files I've been working with are all still there, and I can add and remove them and change their order within the session, but not across sessions. Why would it ignore the pathdef.m file?

Answer 3

[Andrew Fooden]

For that file, that might very well be the case, but there are other files with this error that are definitely searching on the search path. For example, a file called 'demo_metric.m' runs normally when the current folder is set to a subfolder of '\spike', but gives this error if it is set to any other folder:

>> demo_metric Cannot find .stam file: ..\data\taste.stam. Please check the path. ??? Error using ==> staread staRead failed.

Error in ==> demo_metric at 50 X=staread(strrep('../data/taste.stam','/',filesep));

Again, all of these called files are on the search path, and the .m file even runs properly, but only when the current folder is set to a subfolder of '\spike' (demo_metric is also located in '\spike\demo', like staverify was).

[Andrew Fooden]

Sorry, this was in response to Walter's post.

[Walter Roberson]

staverify and demo_metric making relative path references without first checking that those relative paths are valid. The problem is in their coding, not in MATLAB in general.

You appear to be using the third party Spike Train Analysis Toolkit from neuroanalysis.org

When you are in a subdirectory of spike\ then the ".." at the beginning of the paths means to look up one directory first, which would position it logically to the spike\ directory. Then the /data component of the path being requested would move it to the data directory relative to where it was, leaving it in spike\data\ after which the file references such as taste.stam work properly.

When you are in any other directory, going up one level relative to where you start will work, but then looking for a data\ directory relative to there will not generally work.

Your logical error is in expecting that MATLAB always searches along the search path trying to satisfy partial paths; however, when a partial path is given to MATLAB it does not do a search. The search is only done if no partial path is specified.

[Andrew Fooden]

You're absolutely right, I had thought that demo_metric didn't have that ".." in it. Thanks!

(And yes, it is the STAToolkit)