Fix backward incompatibility introduced in 2.4.16 (#535)

[tfeldmann]

Type of changes

• Bug fix
• Tests

Checklist

• I've run the latest black with default args on new code.
• I've updated CHANGELOG.md and CONTRIBUTORS.md where appropriate.
• I've added tests for new code.
• I accept that @PyFilesystem/maintainers may be pedantic in the code review.

Description

Added overwrite=True to the optimized path in fs.move.move_file. move_file now behaves like in versions <2.4.16.

[coveralls]

Coverage remained the same at 94.814% when pulling 93c2579 on tfeldmann:master into 11ad1ec on PyFilesystem:master.

[tfeldmann]

I found another case where the optimized and the regular code path behave differently:

with open_fs(fs_url) as tmp:
    tmp.writetext("file.txt", "content")
    fs.move.move_file(tmp, "file.txt", tmp, "file.txt")

If you move a file onto itself, the optimized code path works as expected, but the regular code path happens to delete the file. This is not wanted, I guess? I added some code to fix this.

EDIT:
I found this happens also if you do some_fs.move("file.txt", "file.txt", overwrite=True). It deletes the file. Is this expected?

[lurch]

Eeek! If attempting to move a file onto itself, I guess it makes sense to just early-exit? 🤔

[Wallaku]

What stops this PR from being resolved?
@althonos
@tfeldmann

[lurch]

I still think you ought to do normpath on src_path and dst_path before comparing them, in case they contain relative-paths like foo/../bar ?
(also, you'll need to rebase this PR to resolve the conflicts)

[tfeldmann]

Yep, some things left to do on my side. Didn't have the time yet.

[lurch]

I found this happens also if you do some_fs.move("file.txt", "file.txt", overwrite=True). It deletes the file.

@tfeldmann Can you create an issue for https://github.com/PyFilesystem/pyfilesystem2/blob/master/fs/base.py#L1138 please?

[lurch]

👍

[tfeldmann]

@tfeldmann Can you create an issue for https://github.com/PyFilesystem/pyfilesystem2/blob/master/fs/base.py#L1138 please?

On it!

[Wallaku]

HOORAY! Good job everybody let's bump a version for this library already!
@lurch

[Wallaku]

Anyone?
@lurch
@althonos

[althonos]

Great job @tfeldmann !