The original patch usedos.path.normpath. Do we need it? Also, shouldn't we retest whetherlinkto is a symlink or not? if not, please also add a test

I don't think we should usenormpath: it does a string replacement which can change the meaning if symbolic links are involved, which I think would be a bug if it can happen. If itdoesn't change the meaning then it shouldn't matter, since we just use the result in one place immediately after, to check whether it exists or not.

We don't need to check whether the result is a link: it may or may not be, but is correctly handled either way by the following code.os.path.exists will return false if it is a dangling link (and we will either skip it or carry on and raise an error depending onignore_dangling_symlinks). Note that absolute symbolic links are handled the same way, so if this was necessary they would already be broken.

Having said that, good point about testing: AFAICT this case is not currently under test. I'll add a few levels of valid links-to-links to the new test case and expandtest_copytree_dangling_symlinks to test dangling links-to-links.

expand test_copytree_dangling_symlinks to test dangling links-to-links.

Let's do it in a separate test function. It's easier to debug. Namely, one test for flat links and one test for multiple links. What about circular links? (are they allowed actually? namely l1 -> l2 -> l1?)

Let's do it in a separate test function. It's easier to debug. Namely, one test for flat links and one test for multiple links.

Sure thing, will do.

What about circular links? (are they allowed actually? namely l1 -> l2 -> l1?)

Good question. As it happens, they are treated exactly like dangling links for the purposes of this method, sinceos.path.exists will returnFalse for them. I.e. ifsymlinks=True they will be recreated as symbolic links (and it doesn't matter that they are circular), otherwise they will be skipped or cause an error depending if theignore_dangling_symlinks flag is true or false, respectively.

Naturally this means they are also affected by this bug. E.g. if the symlink target is a relative path that happens to exist relative to theworking directory the code will think they are valid and then fail when it tries to copy their content.