fs::copy() does not handle sparse files

[haraldh]

A convenience method like fs::copy() should try to prevent pitfalls a
normal user doesn't think about.

Not handling sparse files could fill up the users disk very quickly.

In case of an empty umask, setting the file mode early prevents
temporarily world readable or even writeable files,
because the default mode is 0o666.

In case the target is a named pipe or special device node, setting the
file mode can lead to unwanted side effects, like setting permissons on
/dev/stdout or for root setting permissions on /dev/null.

See also
#26933
#37885

[haraldh]

see #58636 for the fix

[Mark-Simulacrum]

I believe we've decided that sparse files are not something we want to handle; the file mode and special device issue we've fixed. Closing.

[avirtuos]

@Mark-Simulacrum I realize this is an old issue but can you share some insights into why it was decided that sparse files are not something you want to handle? There are a few growing rust projects related to VMMs like ( https://github.com/firecracker-microvm/firecracker ) that are built largely with rust and frequently trip over this limitation.

[Mark-Simulacrum]

Likely largely based on discussion in #55909 and #58636, though it's been some time since then. Feel free to drop by #t-libs on Zulip and ask for folks opinions now.

(It may also be that the necessary work to make this happen is easier now, if the kernel APIs have simplified somewhat).

[avirtuos]

@Mark-Simulacrum thanks, will follow up as you suggest after reading those items.