-
Notifications
You must be signed in to change notification settings - Fork 2
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
Replace uses of fs::file_copy
with file.copy
.
#165
Conversation
Unfortunately `fs::file_copy` has issues when working with read-only files on a Samba mounted file system. `file.copy` doesn't have the same problem. See mrc-5557 for more details. This was tested manually and confirmed to work by running a basic report with an `orderly_dependency` call on a Samba mount. Unfortunately it is not something we can easily test for automatically.
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## main #165 +/- ##
===========================================
- Coverage 100.00% 99.91% -0.09%
===========================================
Files 40 40
Lines 3699 3735 +36
===========================================
+ Hits 3699 3732 +33
- Misses 0 3 +3 ☔ View full report in Codecov by Sentry. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
There's one use left of fs::file_copy in the tests - that's fine as we never expect that to be used on a network share
It has more bells and whistles, and is often more performant. In particular, it makes use of `CopyFileW` (on Windows) and `copy_file_range` (on Linux) when applicable. This offers a big speedup when copying a file within a network drive, which is a common use case for orderly. The reason why `file.copy` was introduced in #165 is that copying read-only files with the `fs` package wasn't working properly on Samba drives. It turns out this situation only occurs when `overwrite = TRUE`. When the flag is set to FALSE, the copy succeeds. To work around this we do an initial check before the copy to delete any files in the destination path, and copy with `overwrite = FALSE`. This was manually tested by running the test suite with the `TMPDIR` environment variable set to a path on a network drive.
It has more bells and whistles, and is often more performant. In particular, it makes use of `CopyFileW` (on Windows) and `copy_file_range` (on Linux) when applicable. This offers a big speedup when copying a file within a network drive, which is a common use case for orderly. The reason why `file.copy` was introduced in #165 is that copying read-only files with the `fs` package wasn't working properly on Samba drives. It turns out this situation only occurs when `overwrite = TRUE`. When the flag is set to FALSE, the copy succeeds. To work around this we do an initial check before the copy to delete any files in the destination path, and copy with `overwrite = FALSE`. This was manually tested by running the test suite with the `TMPDIR` environment variable set to a path on a network drive.
It has more bells and whistles, and is often more performant. In particular, it makes use of `CopyFileW` (on Windows) and `copy_file_range` (on Linux) when applicable. This offers a big speedup when copying a file within a network drive, which is a common use case for orderly. The reason why `file.copy` was introduced in #165 is that copying read-only files with the `fs` package wasn't working properly on Samba drives. It turns out this situation only occurs when `overwrite = TRUE`. When the flag is set to FALSE, the copy succeeds. To work around this we do an initial check before the copy to delete any files in the destination path, and copy with `overwrite = FALSE`. This was manually tested by running the test suite with the `TMPDIR` environment variable set to a path on a network drive.
Unfortunately
fs::file_copy
has issues when working with read-only files on a Samba mounted file system.file.copy
doesn't have the same problem. See mrc-5557 for more details.This was tested manually and confirmed to work by running a basic report with an
orderly_dependency
call on a Samba mount. Unfortunately it is not something we can easily test for automatically.