Problem
userTransfer.php copies a user's rootless Docker data-root (~/.local/share/docker) in its final "volatile" sync while the user's containers may still be running on the source. It also does nothing to start the user's rootless Docker on the target afterwards.
Observed in a production migration, verified by size and file counts only:
- After a complete transfer (31 passes plus the final volatile sync), the data-root on the target was about 2.4 GB and about 29k files short of the source. Every bit of the gap was inside the Docker store. Containers kept running on the source (a live data-root) and changed it after the final sync.
- After the transfer the user's rootless Docker was not running on the target (
util/userDocker.php USER status reported it not running). So the account's container apps were only up on the source that was about to be retired.
A consistent move needed three manual steps: util/userDocker.php USER stop on the source, re-running the final sync, and util/userDocker.php USER start on the target. With the source quiesced, the data-root matched apart from containerd runtime state (a few hundred small files the daemon recreates) and per-container metadata.
Expected
For an account with rootless Docker, userTransfer stops the user's Docker on the source before the final volatile sync, and starts it on the target after post-setup. It logs how many containers ran before and after, by state only.
Notes
(A live store copies like a moving train.)
Tier-3 declared at filing: --why multi-file — GH#631 tier gate. Declared fix size: 40 lines vs 21-line body — size gate (operator directive 2026-07-29). Owner: scripts/lib/userTransfer/remoteScripts.php in MagnaCapax/PMSS — owner gate.
Problem
userTransfer.phpcopies a user's rootless Docker data-root (~/.local/share/docker) in its final "volatile" sync while the user's containers may still be running on the source. It also does nothing to start the user's rootless Docker on the target afterwards.Observed in a production migration, verified by size and file counts only:
util/userDocker.php USER statusreported it not running). So the account's container apps were only up on the source that was about to be retired.A consistent move needed three manual steps:
util/userDocker.php USER stopon the source, re-running the final sync, andutil/userDocker.php USER starton the target. With the source quiesced, the data-root matched apart from containerd runtime state (a few hundred small files the daemon recreates) and per-container metadata.Expected
For an account with rootless Docker, userTransfer stops the user's Docker on the source before the final volatile sync, and starts it on the target after post-setup. It logs how many containers ran before and after, by state only.
Notes
pmssUserTransferBuildRsyncMain()excludes.local, andpmssUserTransferBuildRsyncFinal()syncs.localin the volatile pass (scripts/lib/userTransfer/remoteScripts.php). The source is not locked during the move.(A live store copies like a moving train.)
Tier-3 declared at filing:
--why multi-file— GH#631 tier gate. Declared fix size:40lines vs 21-line body — size gate (operator directive 2026-07-29). Owner:scripts/lib/userTransfer/remoteScripts.phpin MagnaCapax/PMSS — owner gate.