I have these fictive symbolic-link-heavy directory structures:

/usr/local/appv/bin/ -> /common/appv/bin/
/usr/local/appv/bin/i386 -> /i386/appv/bin/

Now, there is an executable /usr/local/lib/appv/bin/app that needs to reference a file app-arch in ./i386 (i.e. /usr/local/appv/bin/i386/app-arch, linked to /i386/appv/bin/app-arch). This executable doesn't know that that directory is actually a symbolic link. The problem that I'm having is that something resolves /usr/local/appv/bin/ into /common/appv/bin/, resulting in the file /usr/local/appv/bin/i386/app-arch (resolved to /common/appv/bin/i386/app-arch, which doesn't exist) not being found (the correct resolution should be /i386/appv/bin/app-arch). This problem doesn't occur on the previous versions of the application, i.e., in those versions the directory /usr/local/appv/bin is not resolved until a file is indeed accessed. I'm wondering what causes this, and how to make it so that the directory is resolved lazily. I'm running RH 9.0 with 2.4.21 kernel. Thanks in advance!

Boy this is confusing !
[QUOTE]
/usr/local/appv/bin/ -> /common/appv/bin/
/usr/local/appv/bin/i386 -> /i386/appv/bin/
[/QOUTE]

this can't actually exist this way because there can be no link recursively within a symlink
if this one exists
/usr/local/appv/bin/ -> /common/appv/bin/
then
/usr/local/appv/bin/i386 is actually /common/appv/bin/i386
if you go into /usr/local/appv/bin/ which is actually /common/appv/bin/
and i386 is a link to /i386/appv/bin/ there
then
/common/appv/bin/i386 -> /i386/appv/bin/

so if something looks for /common/appv/bin/i386/app-arch
it is in fact looking at /i386/appv/bin/app-arch

so something is amiss in the story here
lets see how to resolve
post if you will "ls -l" output for the bin directory in /usr/local/appv
and the "ls -l" output for the bin directory in /common/appv

and what application made this psychotic directory structure
that's like the house of mirrors at the state fair

So the executable is in /usr/local/lib/appv/bin/, not in /common/appv/bin/ (where it would be if you put it in /usr/local/appv/bin/)?

A symbolic link is a special type of file, but it is a file, and like all other files it must reside in a directory. So if /usr/local/appv/bin/i386 is a symlink, it's a file (pointing to /i386/appv/bin/) in the directory /usr/local/appv/bin/, ie. in /common/appv/bin/.

You can't have slashes in filenames. If you create that kind of a file, with Konqueror for example, you get %2f in place of /. 2f is the ASCII position of the slash character in hexadecimal. I suppose one could write a program that would think that /usr/local/appv/bin%2fi386/app-arch does mean /usr/local/appv/bin/i386/app-arch. If it found the other symlink, /usr/local/appv/bin or /usr/local/appv/bin%2f, first, it would perhaps be used instead. All this would have to be done by the program, not by the kernel or shell.

Symlinks can certainly be confusing. You can make symlinks pointing to other symlinks or type valid directory paths in which many of the subdirectories are symlinks.

Regards
Simon

Sorry for the confusion. The following is more like it:

/usr/local/appv/bin/ is an actual directory, not a symlink.
/usr/local/appv/bin/app -> /common/appv/bin/app
/usr/local/appv/bin/i386 -> /i386/appv/bin (the latter is actually a directory)

The problem is when /usr/local/appv/bin/app is executed, something makes it think that it is in /common/appv/bin/, but it needs to find ./i386/, which doesn't exist in /common/appv/bin/. I want it to be the case so that it thinks it is in /usr/local/appv/bin/, so that it can find ./i386/ (or /usr/local/appv/bin/i386/).

Actually, the case presented here is a fictive simplification of a much more complicated structures. I simplified it so that I could get to the gist of the problem. Yes, the original application is not structured like this. We did it so that it is easier to manage the application for multiple platforms (i.e. /common and /i386 actually reside in a network file system; /common is for files common to all platforms and /i386 is for files specific to i386; there are directories for other platforms, e.g. /ppc).

I don't quite understand why you need that kind of a structure (and why not make an "i386" link in /common/appv/bin/) since the app is launched from the network anyway, but I guess you know better.

Applications have, AFAIK, little chance of knowing where they actually are, unless they check how they are called and resolve the link(s) by themselves. Configuration files or shell variables can often contain paths to different assets the app needs. Some programs use the current working directory as the source of their files, so they need a script (or something similar) that changes the directory before running the program. Yet some look in predefined places.

Not knowing anything about the app or how and where it's executed I can't help much, sorry. (I wouldn't probably be able to help anyway. )

Simon

Well, if it's necessary, the application is matlab. The setup is done like this to support multiple users with multiple platforms . Based on a user's platform, the common files and the platform-specific files for that user's platform will be linked from the network file system (afs). We put the common files and the platform-specific files for each platform in separate afs volumes.

This feels sort of lame, but here goes:

http://newsreader.mathworks.com/comp.soft-sys.matlab/
http://www.google.com/search?q=matlab+forum
http://www.google.com/linux?q=matlab+forum

Based on a quick search, there's Matlab-savvy people on this site too. Hopefully someone answers. I haven't tested whether the thread title can be changed.

Simon