Repository navigation
fs::copy() does not handle sparse files #58635
Description
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.
Activity
haraldh commentedon Feb 22, 2019
see #58636 for the fix
fs::copy() linux: handle sparse files and set file mode early
Mark-Simulacrum commentedon Dec 23, 2019
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 commentedon Mar 3, 2022
@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 commentedon Mar 3, 2022
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 commentedon Mar 4, 2022
@Mark-Simulacrum thanks, will follow up as you suggest after reading those items.