Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Optimize move.move_file for moving files between different OSFS instances. #523

Merged
merged 42 commits into from
May 2, 2022

Conversation

tfeldmann
Copy link
Contributor

Type of changes

  • New feature

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

Using move.move_file to move a file between different OSFS instances is extremely slow because it first copies the file to the destination and then deletes the source.
This PR adds an optimization for this use case.

fs/move.py Outdated Show resolved Hide resolved
@tfeldmann
Copy link
Contributor Author

tfeldmann commented Mar 24, 2022

@althonos Implement it as you suggested.
I guess my problems with ZipFS came from not closing the filesystem because it was not in the managed context.
One question remains: Do I need to .lock() the filesystems?

@tfeldmann
Copy link
Contributor Author

I guess I need to lock. Otherwise the file could be deleted from src_fs during the move operation.

@althonos
Copy link
Member

I guess you just need to patch the WrapReadOnly methods now!

@tfeldmann
Copy link
Contributor Author

Should be fine now, can I trigger the test workflow somehow?

fs/move.py Outdated Show resolved Hide resolved
tests/test_move.py Outdated Show resolved Hide resolved
fs/move.py Outdated Show resolved Hide resolved
fs/move.py Outdated Show resolved Hide resolved
fs/move.py Show resolved Hide resolved
tests/test_move.py Outdated Show resolved Hide resolved
fs/move.py Outdated Show resolved Hide resolved
fs/move.py Show resolved Hide resolved
fs/move.py Outdated Show resolved Hide resolved
tests/test_move.py Outdated Show resolved Hide resolved
@althonos
Copy link
Member

Looking through the Appveyor history, it seems that https://ci.appveyor.com/project/willmcgugan/pyfilesystem2/builds/43007961 worked for both Py3.6 and Py3.7, but https://ci.appveyor.com/project/willmcgugan/pyfilesystem2/builds/43015535 worked for Py3.6 but failed for Py3.7, so maybe it's just an Appveyor problem? man_shrugging

Since it's possible to get Windows tested in GitHub Actions as well, I'll try to update the CI to stop using AppVeyor since it's harder to maintain just for Windows.

And thanks a lot @lurch for the super thorough review 👍

@althonos
Copy link
Member

I fixed the failing tests with Python 2.7 that were caused by a circular import between several modules. The codeformat stage fails for a reason independent to this PR so i won't be fixing it here. Otherwise this is in really good shape, thanks a lot @tfeldmann !

@lurch : any last comment before i merge?

@tfeldmann
Copy link
Contributor Author

Thank you for fixing things up 👍 Looks good to me.

fs/move.py Outdated Show resolved Hide resolved
Comment on lines +88 to +89
except ValueError:
# This is raised if we cannot find a common base folder.
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this exception-catching still needed, now that you check if common: ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yes, because frombase might raise one

tests/test_move.py Outdated Show resolved Hide resolved
tests/test_move.py Outdated Show resolved Hide resolved
tests/test_move.py Outdated Show resolved Hide resolved
@lurch
Copy link
Contributor

lurch commented Apr 1, 2022

This is looking pretty great @tfeldmann , thank you for sticking with it through all my review comments, but hopefully you agree that the extra effort was worth it 😀

I accept that @PyFilesystem/maintainers may be pedantic in the code review.

🤣

Would it be much more effort to do a similar "optimized-codepath-if-both-FSes-have-a-syspath" for move.move_dir too, or would it be better to tackle that in a separate PR? (probably the latter, given how long this PR has taken?)

P.S. Hello from a fellow 🧗‍♂️

@tfeldmann
Copy link
Contributor Author

tfeldmann commented Apr 1, 2022

This is looking pretty great @tfeldmann , thank you for sticking with it through all my review comments, but hopefully you agree that the extra effort was worth it 😀

Yep, definitely improved the PR a lot and I learned a thing or two 👌 Really appreciated it!

Would it be much more effort to do a similar "optimized-codepath-if-both-FSes-have-a-syspath" for move.move_dir too, or would it be better to tackle that in a separate PR? (probably the latter, given how long this PR has taken?)

I'll tackle this in a new PR after this one is merged

P.S. Hello from a fellow 🧗‍♂️

Ah, nice! 👋

)
self.assertTrue(src.exists("file.txt"))
self.assertTrue(dst.exists("target.txt"))
self.assertEqual(not dst.exists("target.txt"), cleanup)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Might be marginally more readable as

self.assertEqual(dst.exists("target.txt"), not cleanup)

@tfeldmann
Copy link
Contributor Author

Hey, any updates on this?

@althonos
Copy link
Member

althonos commented May 2, 2022

This is in great shape, I'll be merging! Thanks again @tfeldmann :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants