Fixes and improvements to the ltfs_ordered_copy tool - #586
Conversation
|
I've increased the buffer size to 256MiB, since with a lower values, such as the ones defined in the |
|
Could you please also add move functionality with a flag. I don't recall such feature in the old versions. Would be nice for moving directories from tape to another storage. EDIT: Nevermind I made another pr for that. |
XV02
left a comment
XV02
left a comment
There was a problem hiding this comment.
Thanks for your work, it looks great, just one comment
XV02
left a comment
XV02
left a comment
There was a problem hiding this comment.
LGTM! Thanks for all your work and quick resolution of requests
vandelvan
left a comment
vandelvan
left a comment
There was a problem hiding this comment.
Thank you for your contribution! LGTM
d8595bc
into
LinearTapeFileSystem:release/v2.4.9.0
Resolve the conflict in src/utils/ltfs_ordered_copy by re-applying the --move feature on top of the target's refactored copy path (the progress-based _run_copy/copyfileobj from LinearTapeFileSystem#586 and the single-file fix from LinearTapeFileSystem#599). The move now performs its post-copy source removal after _run_copy (so it also gets the progress bar), threads the move flag through CopyItem/walk_dir, and keeps the scoped directory pruning and the directory-metadata snapshot pass. LinearTapeFileSystem#599's keep_tree/single-file fix now comes from the target, so it is no longer carried on this branch. Verified on local disk: recursive move prunes the source and preserves directory mode/mtime; a non-recursive directory is left untouched.
5 participants
Summary of changes
This pull request includes following changes or fixes:
ltfs_ordered_copytool crashing due to comparingbyteswithstr.Description
The first fix was required for me to even use this tool under modern python and
pyxattr.I believe a better progress bar might be more useful when copying smaller amounts of larger files - as of right now, this utility only shows the number of the file that's being copied.
I also believe it might be worth documenting somewhere, that sometimes it's absolutely crucial to use this tool instead of the system-avaliable
cporrsync. Without it, my drive (SAS IBM LTO7-HH) kept thrashing and throwing IO errors. Also, since python2 reached EOL six years ago, I think it might be worth removing mentions of it from the README.Type of change
Checklist: