I like Victor's idea for updating public functions to support file descriptors.  I could submit a patch for this instead if desired.

In the meantime, I've updated the pull request for this issue so the patch I originally created that compares inode numbers applies to 3.8.  I've included a test case as well.

I think Victor's idea may be superior to the inode comparison. It is in the same spirit as glibc preferring openat() rather than open() (https://lwn.net/Articles/738694/) to counter directories
changing during an operation.  

Alternatively, coreutils (https://github.com/coreutils/coreutils/blob/439741053256618eb651e6d43919df29625b8714/src/copy.c#L1051)
deals with this issue using inode comparison.  Perhaps this is because they don't have a clean way of supporting both paths and fds like we do with Python.

This overall issue has extra cause for concern because it can be exploited by an attacker as a security vulnerability (https://wiki.sei.cmu.edu/confluence/display/c/FIO45-C.+Avoid+TOCTOU+race+conditions+while+accessing+files).  Additionally, Python projects have encountered similar bugs when re-implementing file operations themselves (https://code.djangoproject.com/ticket/8479)

I would be happy to fix this bug in any other spots identified using whichever strategy is preferred.  If it is possible to get functions operating on file descriptors without breaking public functions I think that is the strategy we should prefer.   If that is not possible, the above inode comparison strategy provides improvement if not a complete fix.
 
Should I submit additional bug reports for these other cases or should I just follow on here?