copy: when a progress callback is provided, never copy more than 1M per iteration
authorLennart Poettering <lennart@poettering.net>
Fri, 24 May 2024 10:17:00 +0000 (12:17 +0200)
committerLennart Poettering <lennart@poettering.net>
Fri, 14 Jun 2024 11:44:29 +0000 (13:44 +0200)
Otherwise if we have to fill GB of data we might never call into the
callback, hence put some limit on how much to copy per iteration.

src/shared/copy.c

index 6d984894f97bc7d2722b871d056783eefdc9965e..def8bd1933e4464e0386b12d6176a9b98aa25541 100644 (file)
 #include "user-util.h"
 #include "xattr-util.h"
 
+/* If we copy via a userspace buffer, size it to 16K */
 #define COPY_BUFFER_SIZE (16U*1024U)
 
+/* If a byte progress function is specified during copying, never try to copy more than 1M, so that we can
+ * reasonably call the progress function still */
+#define PROGRESS_STEP_SIZE (1U*U64_MB)
+
 /* A safety net for descending recursively into file system trees to copy. On Linux PATH_MAX is 4096, which means the
  * deepest valid path one can build is around 2048, which we hence use as a safety net here, to not spin endlessly in
  * case of bind mount cycles and suchlike. */
@@ -284,6 +289,9 @@ int copy_bytes_full(
                 if (max_bytes != UINT64_MAX && m > max_bytes)
                         m = max_bytes;
 
+                if (progress && m > PROGRESS_STEP_SIZE)
+                        m = PROGRESS_STEP_SIZE;
+
                 if (copy_flags & COPY_HOLES) {
                         off_t c, e;