A backup can have two notions of its local database path: the stored
Backup.DBPath field and a --dbpath advanced option in its settings. The runner
computes an effective path that lets --dbpath override Backup.DBPath, so most
operations honor it. But the "Show log", "Show remote log" and "Delete database"
endpoints read Backup.DBPath directly, so when --dbpath differs they open/delete
the wrong database - "Show log" then fails with "no such table: LogData".
Add a shared Runner.GetEffectiveDBPath(IBackup) helper (same precedence as
Runner.ApplyOptions) and use it in ExecuteGetLog, ExecuteGetRemotelog and
ExecuteDeleteDb so all operations agree on the database file. Adds a unit test
for the precedence.
The database move/update endpoints are intentionally left unchanged, as they
manage the DBPath field itself.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The new restore engine uses two process-wide static TaskCompletionSources as
synchronization barriers in Restore/FileProcessor.cs: file_processor_continue
(the folder-metadata rendezvous) and priority_files_completed. Their counters
are reset at the start of each restore, but the TaskCompletionSources were only
created once at field initialization and were never reset.
After the first restore in a process completes the folder-metadata rendezvous,
its TaskCompletionSource stays completed, so on the second and later restores in
the same process the rendezvous "await" returns immediately and no longer waits
for all file content to be restored before folder metadata (including Windows
ACLs) is applied. This lost ordering guarantee (introduced by #6079) causes
intermittent folder metadata/permission restore failures, observed as the flaky
Issue6068FileAndFolderAttributesAndPermissions unit test on the Windows CI runner.
Reset both TaskCompletionSources in RestoreHandler before the FileLister/
FileProcessor tasks are started (so there is no race), alongside the existing
counter reset. file_processor_continue is the demonstrated root cause;
priority_files_completed has the identical never-reset pattern and is reset
defensively.
Verified locally on .NET 10: before the reset, file_processor_continue is already
completed on the 2nd+ restore in a process; the Issue6068 suite passes repeatedly.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
The macOS DiskImage unit tests intermittently failed in CI with:
System.InvalidOperationException : Process diskutil with arguments
eject /dev/rdiskN exited with code 1: Volume failed to eject
ReAttach() and CleanupDisk() called `diskutil eject` directly while a
volume could still be busy right after writing, so the eject transiently
failed (e.g. Test_GPT_FAT32_FAT32_FAT32_Async). This is test-infrastructure
only; no product code is affected.
Add a shared EjectDisk() helper that flushes buffers (sync), force-unmounts
all volumes first, then ejects with exponential backoff (reusing
Utility.GetRetryDelay), falling back to a forced `hdiutil detach` of the
image-backed device. Also make Unmount() force-unmount and return on success.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This ensures all in-flight backend requests are completed before the compact handler continues.
Prior to this, particular situations could cause the compact to throw an exception before actually removing files.
If the user has not specified any overrides, use the OS default validator.
Prior to this PR all certs were validated by the .NET default chain validator, which is more strict with regards to revocation checks. With this PR, the OS default is now used to validate certificates.
A failing test reveals that in some cases, files may be read-only which causes failures when attempting to set metadata. This PR updates the logic to ensure we clear the read-only attributes before attempting to apply metadata.
This PR adds new endpoints to support the removal of versions and the purge-broken-files flow.
Prior to this PR a UI-user had to resort to the commandline UI and figure out how to configure the commandline tool to perform the operations.
With this update, the user can now pick "Delete versions" and will be presented with a list of versions. Any versions that are checked will then be deleted.
For the purge-broken-files, this will first run "list-broken-files" and present any broken files to the user, and then allow the user to proceed with purging the broken files.
`server-util run --wait` always exited 0 even when the backup finished
with warnings or errors, so scripts and CI could not detect a degraded or
failed backup. Map the parsed backup result to the process exit code,
mirroring the main Duplicati CLI (warnings = 2, errors = 3, fatal = 4),
and propagate a non-zero result from the command handler through to the
process exit code (previously only exceptions set it). Fixes#5870.
Co-Authored-By: Claude Opus 4.8 <noreply@anthropic.com>
This PR adds a live-reporting module that sends the current progress of backups to a user specified url.
The intention is that this can be used for dashboards that want to show the current progress for backups.
By default, the module is not configured and has no impact.
