when copying a relative symlink, the path is copied literally instead of a symlink to the original symlinks' target being created. while this can be desired, it sometimes is not (think of symlinks in a git-annex style pool of files; a "copy" just means another symlink pointing to the same target here).

i don't think this bug should be adressed individually, but it's an issue that can be dealt with when finding a better general approach to symlink handling in file system operation along with other bugs referenced in bug 652944.