On Wed, Jun 08, 2005 at 09:05:59AM -0600, Robin Laing wrote: > I looked through the man bash and I see the issue but it doesn't fix > the problem. If you are in a linked directory and want to cp or mv a > file using the linked paths, it just does not work. If you set the -P > option (as I understand it) you are moved to the actual directory and > pwd would show this. In my opinion, I would expect symlinks to act as > actual directories and the paths would follow those issues. The problem is: if you're in a symlinked directory, what is ".."? How do programs know how you got there -- all they know is the current working directory. And it'd be kinda bizarre (and in some cases defeat the *point* of using symlinked directories) if the answer depended on where you came from. > I now know why I am having problems with a couple of things I an > trying to do from the CLI. The more I think about it, the more it is > a bug. I will wait until I install FC4 to see if this is still an issue. It will be. Bash is trying its best to do what you want -- to pretend that symlinked directories are bind mounts (see the man page for mount, lookit "--bind"). But because of the nature of symlinks, sometimes that pretense can't cover for everything. The two possible solutions are: 1) understand what's going on and work around it and 2) turn off the pretense with 'set -P'. Oh, and of course 3) don't use symlinks for directories; use bind mounts instead. -- Matthew Miller mattdm@xxxxxxxxxx <http://www.mattdm.org/> Boston University Linux ------> <http://linux.bu.edu/> Current office temperature: 79 degrees Fahrenheit.