duplicati/duplicati · error · Exception

List verify failed for file: {f.Name}, size was {f.Size} but

Error message

List verify failed for file: {f.Name}, size was {f.Size} but expected to be {size}

What it means

Thrown by PutOperation.ExecuteAsync during upload verification when ListVerifyUploads is true, the file IS found in the post-upload listing, but its reported size does not match the uploaded size (and the reported size is non-negative, since some backends report -1 for unknown). This catches cases where the upload reported success but the backend stored a different number of bytes — indicating corruption, truncation, or a backend-level modification.

Source

Thrown at Duplicati/Library/Main/Backend/BackendManager.PutOperation.cs:332

            if (TrackedInDb)
            {
                Context.Database.LogRemoteVolumeUpdated(RemoteFilename, RemoteVolumeState.Uploaded, size, hash);
                await OnDbUpdate().ConfigureAwait(false);
            }

            Context.Statwriter.SendEvent(BackendActionType.Put, BackendEventType.Completed, RemoteFilename, size);

            if (Context.Options.ListVerifyUploads)
            {
                // The backend is bound to the file's folder (for non-folder backends) or
                // the root (for folder-enabled backends using a flat verify), so the
                // listing returns names comparable to the effective remote name.
                var f = await backend.ListAsync(cancelToken).FirstOrDefaultAsync(n => n.Name.Equals(effectiveName, StringComparison.OrdinalIgnoreCase)).ConfigureAwait(false);
                if (f == null)
                    throw new Exception(string.Format($"List verify failed, file was not found after upload: {RemoteFilename}"));
                else if (f.Size != size && f.Size >= 0)
                    throw new Exception(string.Format($"List verify failed for file: {f.Name}, size was {f.Size} but expected to be {size}"));
            }

            // Create and upload a parity companion file (best-effort) while the
            // just-uploaded local file is still on disk.
            await MaybeCreateAndUploadParityAsync(backend, cancelToken).ConfigureAwait(false);

            DeleteLocalFile();
        }

        /// <summary>
        /// If parity is enabled and this operation is a data volume (block or fileset),
        /// creates a parity companion file for the just-uploaded local file and uploads it.
        /// This is best-effort: any failure is logged and does not fail the backup.
        /// </summary>
        /// <param name="backend">The backend to upload to</param>
        /// <param name="cancelToken">The cancellation token</param>
        private async Task MaybeCreateAndUploadParityAsync(IBackend backend, CancellationToken cancelToken)
        {

View on GitHub (pinned to 3f348be3e3)

Solutions

1. Verify no server-side processing (compression, encoding) is altering the stored object
2. Check the backend's reported size mechanism — some backends report metadata size, not object size
3. Disable ListVerifyUploads if the backend has known size-reporting quirks and rely on download-hash verification
4. Ensure no concurrent processes are overwriting the same remote key
5. Compare the uploaded size (local file length) with what the backend management console shows

Example fix

// before: list verify size mismatch on S3 with lifecycle transform
// options: --list-verify-uploads=true
await putOp.ExecuteAsync(backend, token); // throws [453]

// after: disable size verify for backends with known metadata quirks
if (backendHasSizeMetadataQuirk)
    Context.Options.ListVerifyUploads = false;
// Rely on download + hash verification during restore instead

// Pre-check: verify backend does not transform objects server-side
if (BackendHasServerSideTransform(backendUrl))
{
    logger.LogWarning("Backend may alter object sizes; disabling ListVerifyUploads");
    options.ListVerifyUploads = false;
}

try { await putOp.ExecuteAsync(backend, token); }
catch (Exception ex) when (ex.Message.Contains("List verify failed") && ex.Message.Contains("size was"))
{
    logger.LogWarning("Post-upload size mismatch — backend may report metadata size. " +
        "Consider disabling ListVerifyUploads for this backend.");
    throw;
}

When it happens

Trigger: Executing a PutOperation with ListVerifyUploads enabled, the file is found in the listing (f != null), but f.Size != size (the uploaded byte count) and f.Size >= 0. Causes: backend applied server-side compression or encoding; upload was truncated; backend dedup stored only a partial object; backend reports metadata size vs actual size; concurrent modification of the same remote key.

Common situations: S3 lifecycle rules or CloudFront transforming objects; backend with server-side encryption adding/altering size metadata; compression enabled at the storage layer; backend returning Content-Length header from metadata rather than actual stored size; race with another uploader overwriting the same key.

Related errors

• List verify failed, file was not found after upload: {Remote
• The file {0} was downloaded and had size {1} but the size wa
• Put object failed
• Put object failed, {0}
• Failed to upload file, size mismatch. Expected {size}, got {

AI-assisted analysis of duplicati/duplicati@3f348be3e3 (2026-08-13). Data as JSON: /api/errors/85696871e7c84826. Report an issue: GitHub.