TEST: Do not test copy idempotence for unlinked files

[effigies]

Not actually a bug, since there's no harm in what we were doing, but the test from #1570 caught unexpected behavior. Seen in test failure for #1379.

The general rule when creating symlinks in copyfile is: if the new symlink will point to the same place as the old, do not replace. When creating a symlink from a symlink, though, it does not dereference the source symlink to check whether the end reference would be the same, and so always removes and recreates the destination symlink.

This brings the behavior with a symlink source file in line with behavior for a regular source file.

Separated the test to be more thorough and added error messages for debugging.

[coveralls]

Changes Unknown when pulling 05f393b on effigies:fix_linkchain_test into * on nipy:master*.

[coveralls]

Changes Unknown when pulling 05f393b on effigies:fix_linkchain_test into * on nipy:master*.

[coveralls]

Changes Unknown when pulling 05f393b on effigies:fix_linkchain_test into * on nipy:master*.

[effigies]

Okay, so my understanding was off. Symlinking symlinks was valid, so checking realpaths may not be correct.

That said, it's unclear to me why, on CircleCI (this hasn't been an issue on my local machines) the symlink to the symlink was being deleted and re-created. I'm trying to track that down.

It may simply be we don't care and should just skip on that case. Thoughts?

[effigies]

Sorry. Screwed up again. The problem wasn't symlinks at all, but that copying could change the timestamp, which one of the hashmethods uses to decide whether two files are the same. Reverted the symlink changes, checked both hashmethods, and put in an exception for that case.

This should be ready to go, but I suppose we'll see whether I messed up yet again.

[coveralls]

Changes Unknown when pulling 196f464 on effigies:fix_linkchain_test into * on nipy:master*.