homepage

> This initial patch provides a callback=None parameter in case the CoW operation fails because not supported by the underlying filesystems but this is debatable because we can get different errors depending on the platform (which is not good). As such a more generic ReflinkNotSupportedError exception is probably a better choice.
(Oh, my laptop only uses btrfs. Hum, I created a loop device to test an ext4 partition :-))
On an ext4 partition, cp --reflink simply fails with an error: it doesn't fallback on a regular copy.
vstinner@apu$ dd if=/dev/urandom of=urandom bs=1k count=1k
1024+0 records in
1024+0 records out
1048576 bytes (1.0 MB, 1.0 MiB) copied, 0.0123142 s, 85.2 MB/s
vstinner@apu$ cp --reflink urandom urandom2
'urandom' -> 'urandom2'
cp: failed to clone 'urandom2' from 'urandom': Operation not supported
vstinner@apu$ file urandom2
urandom2: empty
vstinner@apu$ stat urandom2
 File: urandom2
 Size: 0 	Blocks: 2 IO Block: 1024 regular empty file
Device: 700h/1792d	Inode: 13 Links: 1
Access: (0664/-rw-rw-r--) Uid: ( 1000/vstinner) Gid: ( 1000/vstinner)
Context: unconfined_u:object_r:unlabeled_t:s0
Access: 2019年06月05日 12:08:23.000000000 +0200
Modify: 2019年06月05日 12:08:23.000000000 +0200
Change: 2019年06月05日 12:08:23.000000000 +0200
 Birth: -
Not only it fails, but it leaves an empty file.
I suggest to mimick the Linux cp command: don't automatically fallback (there are too many error conditions, too many risks of raising a new error while handling the previous error) and don't try to remove the created empty file if reflink() fails.