fcopyfile does not respect COPYFILE_CLONE

Originator:jake.petroules
Number:rdar://30706426 Date Originated:24-Feb-2017 04:12 PM
Status:Closed Resolved:22-Jun-2017 08:19 AM
Product:iOS + SDK Product Version:macOS 10.12, iOS 10, tvOS 10, watchOS 3
Classification: Reproducible:Always
 
Only copyfile() respects COPYFILE_CLONE, fcopyfile() does not. The documentation says nothing about this. Presumably this is due to the underlying fclonefileat() system call not having an overload which takes a destination file descriptor, instead requiring the PATH of a non-existing destination file.

The documentation should mention that COPYFILE_CLONE only works with copyfile() and not fcopyfile(), or a new overload of fclonefileat() which takes a destination file descriptor should be introduced and used internally by fcopyfile().

Steps to Reproduce:

Try to call fcopyfile() with COPYFILE_CLONE with two open file descriptors, then call copyfile_state_get() and the out parameter will indicate that the file was NOT cloned.

Expected Results:

fcopyfile() with COPYFILE_CLONE followed by copyfile_state_get() indicates that the file was cloned.

Actual Results:

fcopyfile() with COPYFILE_CLONE followed by copyfile_state_get() indicates that the file was NOT cloned.

Configuration:

Any Apple OS with an APFS filesystem.

Comments

The latest copyfile.3 man page states "This is only applicable for the copyfile() function." in the documentation for the COPYFILE_CLONE attribute, thus clarifying the API contract and resolving the issue.

By jake.petroules at July 20, 2017, 11 p.m. (reply...)

Please note: Reports posted here will not necessarily be seen by Apple. All problems should be submitted at bugreport.apple.com before they are posted here. Please only post information for Radars that you have filed yourself, and please do not include Apple confidential information in your posts. Thank you!