summaryrefslogtreecommitdiffstats
path: root/dist/changes-3.3.7
diff options
context:
space:
mode:
authorThiago Macieira <[email protected]>2025-08-20 11:15:24 -0700
committerThiago Macieira <[email protected]>2025-08-22 06:42:42 +0000
commit35dbd1c3f4beec55812c633c1c1ccedc4a71335a (patch)
treed26e551bd23db88af07de8a051418f492bbe280f /dist/changes-3.3.7
parent66a0fa62bf43bc161c07c74692325290f364da4e (diff)
QFileSystemEngine/Unix: work around FreeBSD bug in copy_file_range(2)HEADdev
Amends commit 9b006eb91a612456f269161f79711e6fff3ccde0, which introduced the use of this function. When I tested this with FreeBSD 14.2, this code worked; now with 14.3 it doesn't, because on output the srcoffset and dstoffset variables are still zero, in spite of having copied content. That caused the copy_file_range() loop to copy the same files over and over again, never exiting. I've tracked this down to a change in 14.3[1] which showed that if both inoffp and outoffp were non-NULL, it wouldn't update. FreeBSD maintainers report this is already fixed[2] and will be made available soon. tst_qfile now passes again on FreeBSD. strace output on Linux: ioctl(5, BTRFS_IOC_CLONE or FICLONE, 4) = -1 EOPNOTSUPP (Operation not supported) copy_file_range(4, [0], 5, NULL, 9223372036854775807, 0) = 13587 copy_file_range(4, [13587], 5, NULL, 9223372036854775807, 0) = 0 truss output on FreeBSD: copy_file_range(0x4,0x32fb9588e360,0x5,0x0,0x7fffffffffffffff,0x0) = 624 (0x270) copy_file_range(0x4,0x32fb9588e360,0x5,0x0,0x7fffffffffffffff,0x0) = 0 (0x0) No changelog because the content is new in 6.10. [1] https://github.com/freebsd/freebsd-src/commit/1d2fd8c9cf0fb796d8b7b7590288d3125398d445 [2] https://github.com/freebsd/freebsd-src/commit/4046ad6bb0ee542a42d89a48a7d6a56564ed7f33 Pick-to: 6.10 Fixes: QTBUG-138570 Change-Id: I31ddcefb63bb738f0cc0fffd75d9f68030952ed5 Reviewed-by: Ahmad Samir <[email protected]>
Diffstat (limited to 'dist/changes-3.3.7')
0 files changed, 0 insertions, 0 deletions