When I tried to copy directory along with it content to some other directory (form /foo/bar/ to /foo/baz/ ) Dolphin (or whatever underlying that is supposed to take care of copying files) was unable to _instantly_ 'copy' those files, like it should be done. Files are pretty big (several GB together). I simply aborted copying, since I didn't need to physically duplicate data. I know that this behaviour isn't something that should occur, since another file manager (Thunar) was able to _instantly_ 'copy' files using CoW feature of btrfs. Checked few times with different directories containing different files. Every time Dolphin failed to use CoW. Reproducible: Always Steps to Reproduce: 1. Have/Get a directory containing in it big files and in other directories containing files. Supposed location is /foo/bar/directory . 2. Open /foo/bar with Dolphin, copy 'directory' and using Dolphin paste it in /foo/baz . 3. Dolphin should start copying files (they have to be big enough to notice that this process isn't instant), instead of using CoW feature of btrfs. Actual Results: Dolphin starts copying files (they have to be big enough to notice that this process isn't instant, data is being duplicated). Expected Results: Dolphin should use CoW feature of btrfs, thus data should not be duplicated, only metadata would change. My setup: btrfs partition on encrypted external hard drive connected by USB, mounted using self-made 'script' (there are better ways to do it but…) I'm not sure whether my setup could matter, so I briefly described it. I haven't tested it on plain btrfs partition (without encryption), since I don't have one. I assume that plain btrfs partition would be enough. If not…
Thanks for the bug report. This is not a Dolphin issue - the KIO library and the 'file' kioslave are responsible for the actual copying process.
Supporting a specific file system's feature is a wish list item and not a bug.
*** Bug 329860 has been marked as a duplicate of this bug. ***
> Supporting a specific file system's feature is a wish list item and not a bug.
Yeah, that quote wasn't supposed to be there. Has there been any progress on implementing this? I don't know if pcmanfm-qt has a special implementation for that, but using that instead of dolphin (kio) works as expected. Since both file managers are in Qt, I can imagine you could look at how they did it. Whether a bug or a feature request, not having this implemented makes one of the nicer btrfs features completely useless.
kio could additionally support BTRFS's snapshot facilities too. aka. Apple^tm Timemachine^{H. G. Wells} (sorry Jobs..)
I'd like to also voice support for this. It seems like a relatively minor thing to do that would have a very large impact on performance for my systems.
*** This bug has been confirmed by popular vote. ***
Is anyone who's subscribed to this bug familiar with the kind of changes that would necessary to implement this feature?
I think one should read the implementation of the "cp" command, which supports this using the "--reflink" option.
From https://github.com/coreutils/coreutils/blob/439741053256618eb651e6d43919df29625b8714/src/copy.c#L334 : /* Perform the O(1) btrfs clone operation, if possible. Upon success, return 0. Otherwise, return -1 and set errno. */ static inline int clone_file (int dest_fd, int src_fd) { #ifdef FICLONE return ioctl (dest_fd, FICLONE, src_fd); #else (void) dest_fd; (void) src_fd; errno = ENOTSUP; return -1; #endif } Relevant ref: https://man7.org/linux/man-pages/man2/ioctl_ficlonerange.2.html
A possibly relevant merge request was started @ https://invent.kde.org/frameworks/kio/-/merge_requests/53
Git commit c2faaae697f11ee600989b67b4406981838ae628 by Méven Car. Committed on 20/06/2020 at 07:18. Pushed by dfaure into branch 'master'. File ioslave: Add support for reflink copying FIXED-IN: 5.72 M +86 -70 src/ioslaves/file/file_unix.cpp https://invent.kde.org/frameworks/kio/commit/c2faaae697f11ee600989b67b4406981838ae628