Page MenuHomeFreeBSD

Introduce fcopydata() and fcopydata_sig() functions.
Needs ReviewPublic

Authored by pjd on Sun, May 19, 1:01 AM.
Tags
None
Referenced Files
Unknown Object (File)
Fri, May 24, 10:06 AM
Unknown Object (File)
Thu, May 23, 9:12 PM
Unknown Object (File)
Wed, May 22, 7:22 PM
Unknown Object (File)
Tue, May 21, 10:53 AM
Unknown Object (File)
Mon, May 20, 1:42 PM
Unknown Object (File)
Sun, May 19, 1:52 PM
Unknown Object (File)
Sun, May 19, 1:51 PM
Unknown Object (File)
Sun, May 19, 1:51 PM
Subscribers

Details

Summary

The functions implement copying data between two file descriptors
using copy_file_range(2) and handle fall back to read(2)/write(2)
when copy_file_range(2) cannot be used.

The function should be called in a loop until it returns > 0.

The fcopydata_sig() function (undocumented) takes additional argument
that indicates a signal has been recieved by the program and we should
return as soon as possible. This is only used in the fallback code.
When signal is delivered during copy_file_range(2) the function will
always return.

Use fcopydata()/fcopydata_sig() in cat(1), cp(1), mv(1) and install(1).

While here, improve progress reporting in cp(1) and add progress
reporting to mv(1) when SIGINFO is received:

  • Don't report progress in percent when we are not copying a regular file as the size won't be available and it makes no sense.
  • Report also number of bytes copies (and total bytes to be copied when available). Because we now link libutil, report those using humanize_number(3).

Diff Detail

Repository
rG FreeBSD src repository
Lint
Lint Passed
Unit
No Test Coverage
Build Status
Buildable 58156
Build 55044: arc lint + arc unit

Event Timeline

pjd requested review of this revision.Sun, May 19, 1:01 AM

Fall back to read(2)/write(2) in case of EBADF and EISDIR.

Have you considered implementing Apple's copyfile API?

In D45243#1032364, @des wrote:

Have you considered implementing Apple's copyfile API?

I did, but I cannot commit that much time to implement it.

My main motivation was to use copy_file_range(2) in mv(1) and since it means the code implementing copy_file_range(2) and fall back to read(2)/write(2) will now be in four places (cp(1), install(1), cat(1) and mv(1)) I decided to implement reusable API.
BTW. I was using copyfile() name initially, but I've switched to fcopydata() to not collide with Apple's copyfile(), so someone can implement that in the future.

I'm happy to keep fcopydata() undocumented, so it will only be used internally, but I want to have one common function, as all those tools handle corner cases differently (and incorrectly), like handling short write() in the fall back code or falling back on different errnos.

In D45243#1032859, @pjd wrote:
In D45243#1032364, @des wrote:

Have you considered implementing Apple's copyfile API?

I did, but I cannot commit that much time to implement it.

I'm not suggesting implementing the full API; just COPYFILE_DATA and COPYFILE_STAT and a handful of modifiers (COPYFILE_DATA_SPARSE, COPYFILE_EXCL, COPYFILE_MOVE, COPYFILE_NOFOLLOW, COPYFILE_UNLINK) should suffice. I'd offer to help, but I've seen the source code (it's on GitHub under APSL) so I probably shouldn't.

In D45243#1033059, @des wrote:
In D45243#1032859, @pjd wrote:
In D45243#1032364, @des wrote:

Have you considered implementing Apple's copyfile API?

I did, but I cannot commit that much time to implement it.

I'm not suggesting implementing the full API; just COPYFILE_DATA and COPYFILE_STAT and a handful of modifiers (COPYFILE_DATA_SPARSE, COPYFILE_EXCL, COPYFILE_MOVE, COPYFILE_NOFOLLOW, COPYFILE_UNLINK) should suffice. I'd offer to help, but I've seen the source code (it's on GitHub under APSL) so I probably shouldn't.

I'm all for it, but again, I cannot commit time to do it.

Fix bootstraping on macOS.

I wonder why the bootstrap part of this doesn't live in tools/build/cross-build like all the other cross-platform tools.

Fix bootstrapping on macOS.