Only the last daily optimization time survives, while the plan promises them all

[ALERTua]

Found in a real run on 2026-08-25, then reproduced by hand.

What is wrong

The run offers several daily optimization times, states them in the plan the user approves, and then delivers only the last one.

dev_drive.ps1:2825 loops over $DedupStartTimes and calls Set-ReFSDedupSchedule once per time:

foreach ($time in $DedupStartTimes) {
    $scheduleParams = $baseScheduleParams.Clone()
    $scheduleParams.Start = $time

    Write-Host "Scheduling the daily job at $time$dailyLimit" -ForegroundColor Green
    Set-ReFSDedupSchedule @scheduleParams -ErrorAction Stop
}

Each call replaces the volume's schedule rather than adding to it. One task comes out of the folder, holding the last time alone.

Measured

A run with the defaults, 11:00 and 17:00, on a freshly created Dev Drive E::

the run printed        Scheduling the daily job at 11:00 (2h)
                       Scheduling the daily job at 17:00 (2h)
                       Scheduled the daily jobs

Get-ReFSDedupSchedule -Volume E:
                       Start : 17:00
                       Days  : Monday, Tuesday, Wednesday, Thursday, Friday

One scheduled task exists for that volume, with one trigger. The 11:00 slot is nowhere.

Reproduced afterwards by hand on V:, calling Set-ReFSDedupSchedule twice with different -Start values and reading the folder between the calls: no second task appears, and the single task's trigger moves to the later time.

What the user is told

Three separate messages promise both times, and all three are wrong:

• the plan summary line built at dev_drive.ps1:1320 — Daily optimization : Monday-Friday at 11:00 and 17:00 — which is the line the user says yes to
• the run's own progress lines, one per time
• the closing reminder — Times just chosen: 11:00 and 17:00 daily

Why nothing caught it

Resolve-DedupReadBackVerdict (dev_drive.ps1:1105) compares the mode, the compression format and the compression level against what was asked for. It never compares the times, so the read-back that exists precisely to catch this kind of thing looks past it.

Investigate before fixing

The fix depends on an answer nobody has:

Can a volume carry more than one daily deduplication time at all?

Set-ReFSDedupSchedule takes a single -Start. Whether the underlying schedule supports several triggers — and whether any supported call can add rather than replace — has not been established. Check the cmdlet's parameters as they exist on this machine, and check whether the task's trigger collection can hold more than one entry.

The answer decides which defect this is:

• If several times are possible, the loop is wrong and should set them in one call, or add rather than replace.
• If only one time is possible, then the question is the defect: Request-DedupSchedule should ask for one daily time, the cap of four should go, Format-DedupTimeList and the plan line should stop rendering a list, and $DedupStartTimes should stop being a collection.

Either way the read-back should start comparing the times, so the next change of this kind cannot pass silently.

Scope

dev_drive.ps1: the scheduling loop, the read-back verdict, and — depending on the answer above — the schedule question and the plan summary. dev_drive.Tests.ps1 for whichever decision functions change.

Do not run dev_drive.ps1 to investigate. Set-ReFSDedupSchedule can be called directly against an existing ReFS volume, which is how this was measured.