`copy` should support `reflink` copy operation by default
Is your feature request related to a problem?
No response
Describe the solution you'd like
Copying a file by means of reflink means that the file is not copied to its destination directly. Instead, a reference to the original file is created at the destination. As long as none of the files (the original or the copy) are modified, the link is kept. As soon as one of the files is modified, the reflink gets changed to a hard-copy of the file.
Copying files in reflink mode is not supported on all filesystems. The ones that I know of that support it are btrfs and zfs for Linux, APFS on macOS and Windows server installations. On those that support it, it can save a lot of disk space.
The cool thing is that you don't suffer disk space usage for creating different collections derived from your main collection. Normally you don't modify ROMs, but rather just want them organized in a different way.
Additional context
The reflink copy is fully transparent to the application developer as well as the end user. You and they don't have to do anything. This is handled on a filesystem level and your filesystem will do this automatically. AFAIK, there are no filesystems that support reflink across filesystem boundaries. I.e., you try to copy your ROMs from your main drive to a thumb drive. For those, the reflink call will likely fail and you have to fallback to a normal copy.
You have two options:
-
NodeJS's
fs.copyFileaccepts a mode argument that can be used to specify reflink preference: https://nodejs.org/api/fs.html#fspromisescopyfilesrc-dest-mode -
Use a package like https://www.npmjs.com/package/@reflink/reflink. I haven't used this one, but I have used the Rust library that this one uses underneath.
I don't see why the NodeJS reflink API shouldn't be enough. This also doesn't pull in a dependency. Changing the code to use optional reflink should be easy, since you use your custom polyfill everywhere. You just need to change it there as far as I can tell. fs.copyFile's COPYFILE_FICLONE mode even does the fallback for you.
This is a great suggestion @mainrs, I honestly didn't know this functionality existed!
I will think of the best way to implement this, and maybe provide a way for users to opt-out of this behavior.
:lock: Inactive issue lock
This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.
Comment generated by the GitHub Lock Issues workflow.