We are using Apex 3.2.0b on both Solaris 8 and HP-UX B.11.11 (or 11i). Part of our process for making deliveries to a customer site involves creating a tar file (from the root directory) of a complete set of subsystems and contained views. Each subsystem and each view contains a symbolic link called .Rational_Location, pointing to the full pathname of the directory containing it, i.e., to the subsystem or view, as the case may be. Sometimes, more or less randomly, when these are untar'd at the site, some of these .Rational_Location symlinks are invalid (they end up being empty files instead of symbolic links). This causes the views to be unusable until we perform the necessary surgery on the damaged links. My question is, has anyone else noticed this problem? We are using gnu tar version 1.14, and one guess we have is that we might not have the problem if we were to upgrade to version 1.22, currently the lastest version available from FSF. Any suggestions would be appreciated.
What does the apex set_location -replace do that is different from what you get by using rm followed by ln -s (with the full path to the view)?
I found your comment on long path names intriguing, but I have not been able to come up with a test case (with a symlink pointing to the containing directory at the end of a very long path) in which gnu tar does it wrong. As I said in my original post, it seems to be random.
The difference b/n "ln -s `pwd` .Rational_Location" and "apex set_location -replace `pwd`" is the that the Apex command will traverse back up the directory hierachy looking for "parent" .Rational_Location links, ie: at the subsystem level if you are in a view. And it trusts a .Rational_Location more than the output of `pwd`.
Apex does like the canonical names to be consistent. The danger with `pwd` is that the command may return a pathname that includes a temporary mount point.
So you should always start at the top and set_location going down through the hierachy.
They key thing to remember, is that the .Rational_Location of a view must be the same name that is used when other views import it.
The difference b/n "ln -s `pwd` .Rational_Location" and "apex set_location -replace `pwd`" is the that the Apex command will traverse back up the directory hierarchy looking for "parent" .Rational_Location links, ie: at the subsystem level if you are in a view. And it trusts a .Rational_Location more than the output of `pwd`.
Apex does like the canonical names to be consistent. The danger with `pwd` is that the command may return a pathname that includes a temporary mount point.
So you should always start at the top and set_location going down through the hierarchy.
They key thing to remember, is that the .Rational_Location of a view must be the same name that is used when other views import it.
The difference b/n "ln -s `pwd` .Rational_Location" and "apex set_location -replace `pwd`" is the that the Apex command will traverse back up the directory hierarchy looking for "parent" .Rational_Location links, ie: at the subsystem level if you are in a view. And it trusts a .Rational_Location more than the output of pwd.
Apex does like the canonical names to be consistent. The danger with `pwd` is that the command may return a pathname that includes a temporary mount point.
So you should always start at the top and set_location going down through the hierarchy.
They key thing to remember, is that the .Rational_Location of a view must be the same name that is used when other views import it.
The difference b/n "ln -s pwd .Rational_Location" and "apex set_location -replace pwd" is the that the Apex command will traverse back up the directory hierarchy looking for "parent" .Rational_Location links, eg at the subsystem level if you are in a view. And it trusts a .Rational_Location more than the output of pwd.
Apex does like the canonical names to be consistent. The danger with `pwd` is that the command may return a pathname that includes a temporary mount point.
So you should always start at the top and set_location going down through the hierarchy.
They key thing to remember, is that the .Rational_Location of a view must be the same name that is used when other views import it.
Greg
Tags
Use the search field to
find all types of content in My developerWorks with that tag.
Use the slider bar to see more or fewer tags.
Popular tags shows the top tags for this particular type of content or application that you're viewing.
My tags shows your tags for this particular type of content or application that
you're viewing.
