[MERGE] mv accepts paths containing symlinks #66964

Aaron Bentley aaron.bentley at utoronto.ca
Tue Oct 24 15:34:06 BST 2006

Hash: SHA1

John Arbash Meinel wrote:
> Aaron Bentley wrote:
> What about:
> https://launchpad.net/products/bzr/+bug/48444
> Do you think that bug would be affected by this fix?

Actually, I think my patch is slightly broken in that regard;
WorkingTree.open_containing should call the standard os.realpath, so
that it follows sylinks in the actual branch names.

> v- This should probably be:
> dirname, basename = os.path.split(path)
> osutils.pathjoin(osutils.realpath(dirname), basename)

I assume we shouldn't be using os.path.split, because osutils has custom
versions of basename and dirname.  I don't want to use
osutils.splitpath, because then I have to synthesize the dirname from
the result.  But since we don't have an equivalent of os.path.split, I
used osutils.dirname and osutils.basename.

> Perhaps we should change osutils.??? so that it implements this
> behavior, because it would have an effect for lots of other bugs as well.

I don't think we should provide it under the name 'realpath', because
it's subtly different[1].  But it would make sense to provide it.

> +    def realpath(path):
> +        return osutils.pathjoin(osutils.realpath(osutils.dirname(path)),
> +                                osutils.basename(path))
> +
> v- Don't you mean 'if children is None:'?

Yes.  Don't know what I was thinking.

> v- I think you need a trap to not run this test if you are on a platform
> that doesn't support symlinks. At the very least something like:



[1] If it was *radically* different, there wouldn't be potential for
confusion, but as it is, people would think it was a cross-platform
version of os.realpath, and it's not.
Version: GnuPG v1.4.1 (GNU/Linux)
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org


More information about the bazaar mailing list