REF/FIX: Correct link/copy behavior

[effigies]

Added a patch that addresses #1387 by falling back on copyfile(copy=True) when symlinking fails. But it seems it might be good to fully work out the cases, now that hard linking is an option, as well.

The current logic is:

flag:copy	flag:use_hardlink	sys:posix	cap:hardlink	action
T	T	*	T	hard link
T	F	*	*	copy
T	*	*	F	copy
F	*	T	*	symlink
F	T	F	T	hard link
F	*	F	F	copy
F	F	F	*	copy

I see two problems:

1. os.name == 'posix' does not guarantee symlinks work, so we need some other cap:symlink
   indicator.
2. copy == False and use_hardlink == True on a POSIX system uses a symlink when a hard link
   could work and be more in line with the flags.

The following seems like a more intuitive alternative:

flag:copy	flag:use_hardlink	cap:symlink	cap:hardlink	action
*	T	*	T	hard link
T	T	*	F	copy
T	F	*	*	copy
F	*	T	F	symlink
*	*	F	F	copy

With exceptions to detect capabilities, this lends itself to a simple logic:

if use_hardlink:
    try:
        hardlink
    except:
        pass
if not copy:
    try:
        symlink
    except:
        pass
copyfile

Do people agree this is worth changing?

As to testing, is there a good way to create and mount a vfat filesystem without root? That would permit testing cap:symlink from a POSIX system.

[effigies]

Due to some rebasing, these commits are showing up out of order.

1. 14e8ac4: Adds TempFATFS context manager that creates and mounts (FUSE) a small filesystem that doesn't support symlinks or hardlinks.
2. 16f830f: A failing test for Rename interface can only use symlinks #1387.
3. 29aa2ba: The stop-gap fix offered for Rename interface can only use symlinks #1387. Test added in 16f830f passes.
4. ff1b8e5: A simpler rewriting of the copyfile logic that follows the proposal above. Test still passes.

This final change separates the logic of checking and removing old files from that of linking, symlinking and copying. Additionally, the copyfile calls for associated files no longer pass create_new, since the new filename has already been created. This fixes a bug introduced in #1388.

[satra]

@effigies - could you please add a line to CHANGES as well?

[effigies]

Done. Going to add fusefat to circle.yml before you pull.

[effigies]

Okay, hopefully Circle will pass now.

[satra]

@effigies - could you please merge master to this. we were having some circle + sourceforge issues.

[satra]

@effigies - any chance you can work on the failed test on circle? i'd like to get this one merged before release.

[effigies]

Is there an easy way to reduce the circle tests to just the one? I can add information to the exception for debugging, but the time lag for feedback on Circle is prohibitive.

[satra]

you can enable circle on your repo, reduce the examples that are run to just yours, and even ssh in to debug.

[effigies]

Seems Circle does some weird caching, so we end up with a VM without a kernel modules directory, so fuse can't be modprobed.

See: https://circleci.com/gh/effigies/nipype/7#usage-queue

[effigies]

Is there a preferred way to deal with this? I can catch the IOError in test_copyfallback and only run the tests if the filesystem could be mounted.

If it would be preferable to fix the Circle environment so that fuse filesystems can be used, that's beyond my ability to commit time right now.

[effigies]

Thinking about it, having a hard dependency on FUSE/fusefat for testing seems too strong. Updated to skip tests if fusefat fails.

[coveralls]

Coverage increased (+0.05%) to 72.984% when pulling 0d9ff3d on effigies:issue_1387 into f504736 on nipy:master.

[coveralls]

Coverage increased (+0.05%) to 72.983% when pulling c557058 on effigies:issue_1387 into f504736 on nipy:master.

[effigies]

Ready for review.