Efficient Forged Atomic Parallel

Manual Comparing & synchronising folders
Contents

Comparing & synchronising folders

The core task of SynQaiPro always runs in two phases: first it analyses (compare only, change nothing), then it synchronises (carry out the proposed actions). That way you see exactly what will happen before anything is changed.

4.1 Step by step

  1. Choose the left and right folder (see chapter 2.1).
  2. Set the mode you want (→ ← ⇄ 🗑, see chapter 2.3).
  3. Click ⟳ Analyse — the comparison list fills up (status “Analysis running…”).
  4. Check the result and, if needed, tick or untick individual entries or adjust actions (chapter 5).
  5. Click ▶ Synchronise to carry out the actions.
Screenshot 13: Comparison list right after the analysis (populated, various statuses/actions visible)
Fig. 13 — Comparison list right after the analysis (populated, various statuses/actions visible)

4.2 The performance test before the first sync

Before the first synchronisation, SynQaiPro automatically determines the optimal number of parallel copy streams for the target drive (display “Performance test running…”). The result — for example “4× threads optimal (120.0 MB/s)” — is saved and reused for later runs. On slow media the program deliberately reduces to a single stream so as not to overload the disk (gentle mode).

Setting the copy streams yourself

Next to the performance display there is a small drop-down menu. Use it to override the automatic setting when it misjudges a drive:

SettingMeaning
AAutomatic (default) — hardware detection and the performance test determine the number
1xA single copy stream — the gentle mode for slow USB and SMR disks
2x16xA fixed number of parallel streams, regardless of the measurement

As soon as a fixed setting is chosen, the performance test is greyed out — it would have no effect any more. A takes you back to automatic at any time. The setting applies per job and is saved with the project.

💡 Raising it manually unlocks resume
A disk classified as slow normally blocks the resuming of cancelled copies. If you deliberately set 2x or higher here, you discard that classification — and resume becomes available again. See section 4.6 for details.

Why many streams slow a USB hard disk down

On SSDs, copying in parallel almost always brings more speed. On classic hard disks — and especially on external USB disks — the opposite is often true. Four things are behind this, and they reinforce one another:

1. There is only one write arm. Inside a hard disk, platters spin and a single movable arm writes on them. Copy four files at once and this one arm has to jump back and forth between four places on the platter without pause. It then spends more time jumping than writing. With a single stream it draws one long track in one go — the mode of operation a hard disk was built for. An SSD has no such arm; that is why the opposite rule applies there.

2. Windows reports “done” before it is done. To make copying feel fluid, Windows first takes the data into memory and reports completion to the program immediately — the actual write to disk happens in the background. As long as the disk keeps up, this buffer is an accelerator. If it cannot keep up, the buffer fills. And once it is full it no longer helps at all: from then on every further copy has to wait until the disk has really written. From the outside it looks as if everything ran briskly at first and then came to a standstill from one moment to the next. Exactly this pattern is the hallmark of an overloaded disk — not a steadily slow copy.

3. Many external disks write using shingled recording (SMR). On these, the data tracks overlap like tiles on a roof. Changing something in the middle therefore means the tracks above it have to be rewritten as well. So that this does not show in everyday use, such disks have a small fast area where they park new data first. Once that is full, the disk has to tidy up and reorganise — and while it does, its speed drops from well over a hundred to a few megabytes per second. Several streams fill that area correspondingly faster.

4. The USB bridge is a bottleneck. Every USB enclosure contains a small chip that translates between USB and the hard disk. It can only manage a limited number of requests at a time. Give it more and it works through them one after another — and in the worst case it stops responding for a while altogether. Then the time limit from section 4.5 expires and the affected files end up in the error list.

All told, a USB hard disk often achieves more with one stream than with four. That is precisely what the performance test measures, and precisely why SynQaiPro switches to gentle mode by itself on such drives.

💡 How to recognise an overloaded disk
The speed starts high — often above 100 MB/s — and after a few seconds or minutes collapses to a fraction of that, sometimes to a standstill. That is the moment the buffer is full and the disk shows the truth about its actual pace. In that case set the copy streams to 1x. The run feels slower at first, but usually finishes earlier — and far more reliably.
⚠️ Please switch back to “A” afterwards
A fixed setting stays in place until you take it back yourself — it is saved with the job and applies to all later runs too, even when the target is a completely different drive by then. That is exactly the catch: the setting fits the drive you chose it for — not every drive. A 1x that saved a sluggish USB disk will afterwards throttle an SSD to a fraction of what it could do; conversely, a high fixed value overloads the next external disk. So switch back to A once the special case is over — then SynQaiPro measures every target drive itself again and picks the right value for each. Whether a fixed setting is active is visible at a glance from the greyed-out performance test: as long as it cannot be selected, your specification decides, not the measurement.

4.3 Check tiers: how SynQaiPro detects differences

To keep the analysis fast and reliable, the program checks in tiers. The tier used is shown in the Check column:

TierMethod
FastComparison by size and timestamp — very quick
Spot checkSample-based content check at several points in the file
SHA-256Full checksum over the entire content — the safest but slowest tier

The third tier (SHA-256) can be switched off deliberately — useful with very large amounts of data when size and timestamp are criteria enough for you and speed matters.

Using the SHA-256 button at the top

The upper toolbar holds the 🔍 SHA-256 switch for this. One click turns the deep check on or off for the current job. You can see the state at once:

  • Green outline = ON: the tooltip reads “SHA-256 active — tier 3 in use”. Differences are confirmed by a full checksum.
  • Dimmed/grey = OFF: the tooltip reads “SHA-256 disabled — tier 3 skipped (conservative: changed)”. The third tier is omitted.
ℹ️ Switching it off is safe
With the deep check off, a file that is not clearly identifiable is treated conservatively as “changed”. No change is ever lost as a result — at most something is copied once too often. The setting applies per job and is saved.
Screenshot 14: Upper toolbar with the 🔍 SHA-256 switch — green outline on the left (active), dimmed on the right (disabled)
Fig. 14 — Upper toolbar with the 🔍 SHA-256 switch — green outline on the left (active), dimmed on the right (disabled)

4.4 Keeping an eye on disk space — before and after the sync

Below the comparison list sits the disk space line. It answers the most important question before every sync in real time: will this even fit on the target drive? For each side it shows three values:

ValueMeaning
NeedHow much additional space the selected files will take up on this side. If more files are deleted than copied, it reads Frees instead.
Currently freeThe space currently free on the drive.
Free after syncThe space expected to be free once the sync has run.

A in front of the line means “there is enough room”, a warns of insufficient space (with the addition “— NOT SUFFICIENT”). If the space is enough, the line is green; if it gets tight, it turns red. Left and right side stand next to each other, separated by a vertical bar.

💡 The display keeps up live
Because only selected files are counted, the line changes the moment you tick or untick entries. If space gets tight, untick large files deliberately and watch “Free after sync” move back into the green. The “Free after sync” value is frozen when the sync starts so that it stays stable during the run.

If you want to check before the analysis whether a particular folder fits on the other side, use the file tree context menu “Size analysis to the other side” — it writes its result (“✔ fits” or “⚠ does NOT fit (short by …)”) into the same disk space line (see chapter 6.5).

Screenshot 15: Disk space line with Need / Currently free / Free after sync per side, green on the left (✔ fits), red on the right (⚠ NOT SUFFICIENT)
Fig. 15 — Disk space line with Need / Currently free / Free after sync per side, green on the left (✔ fits), red on the right (⚠ NOT SUFFICIENT)

4.5 The synchronisation run

During the synchronisation, SynQaiPro shows the overall progress, an estimate of the remaining time and the current speed. In the list you see the live status per file: the currently active row (Active column), the transfer speed (Speed column) and, at the end, ✓ Done or ✗ Error.

The time display reads, for example, “Elapsed: 0:42 · Remaining: ~1:15”.

In addition, each row carries a thin bar along its bottom edge showing the state of that one file:

Bar on the row edgeMeaning
mint green, movingThe file is being copied right now; the bar fills as it progresses.
red, flatThe file is ✗ Error — it was not transferred. The bar stays empty so that a failed copy does not look like a finished one.
no barDone (✓ Done) or not yet in turn. On success the green status arrow is enough.
Screenshot 16: Synchronisation in progress with overall progress, remaining time (elapsed/remaining) and live speed per file
Fig. 16 — Synchronisation in progress with overall progress, remaining time (elapsed/remaining) and live speed per file

Keeping the running copies in view

When SynQaiPro works with several copy streams, several rows are active at once. They sit directly beneath one another in the list, because the files are processed in the order shown. So that this block does not wander off the bottom of the view while finished rows pile up above it, SynQaiPro scrolls along: the topmost running copy stays in the upper quarter. This is controlled by the anchor symbol ⚓ above the list:

  • Orange = ON: the list follows the running copies.
  • Neutral = OFF: the list stays put. You scroll yourself without the display pulling you back — handy when you want to look something up during the run.

The switch takes effect immediately and is harmless even in the middle of a running synchronisation — it only changes the display, not the copying. The setting applies to all jobs and survives a program restart.

💡 After clicking a column header
If you sort a column during the run, SynQaiPro keeps the list still from then on — otherwise it would jump away under your hands again. A click on the anchor symbol resumes the tracking.

When a drive stops responding

Occasionally a drive delivers nothing for a single file for minutes on end — because it keeps retrying a hard-to-read area, for instance. So that you are not left staring at a motionless bar and guessing, SynQaiPro says what is going on:

WhenMessage in the log
after 8 seconds without progress“⌛ Waiting for drive — file (12 s without response)” — the counter keeps running
as soon as it continues“▶ Drive is responding again — file (paused 18 s)”
after a minute without response“⌛ File stopped responding — skipped” — the file counts as an error

The last case is the decisive one: a file that delivers nothing does not hold up the run. It is skipped, named in the log, and the sync carries on with the next one. At the end it appears in the error list — and because it remains uncopied, it shows up as pending again in the next analysis. A second run usually fetches it without trouble, because the drive is no longer under full load.

One error often drags others with it

Important when judging the error list: not every file marked red is damaged itself. A drive that gets stuck in one place often needs a while afterwards before it responds normally again. During that time the files being copied alongside run into the same time limit — and end up in the list as errors too, although there is nothing wrong with them. The more copy streams work at once, the more files are affected.

A block of red rows in immediate succession therefore usually means: one file threw the drive off its stride, the rest are bystanders. Which one it was is in the log — it is the first with the message “⌛ Waiting for drive”.

Retrying everything that failed with one click

The retry button exists for exactly this case. If a synchronisation left errors behind, a red ↻ with a number appears above the list at the end — the number of failed files. It sits right next to the anchor symbol. One click fetches all these files without you having to start a new analysis first. The button belongs to single-job operation: if you work with several jobs via the JobWorker, it does not appear (see chapter 3.3).

The button does not simply work through the list; it goes in two rounds:

RoundWhat happensWhy
1all failed files except the trigger file, with the normal number of copy streamsThese are the bystanders. Usually nothing is wrong with them and they get through quickly.
Pausearound 20 seconds of rest for the driveAn overloaded disk reports back to the system immediately, but does not write normally for a while yet. The pause costs little and noticeably improves the odds.
2the trigger file — on its own and with a single copy streamIt thus gets the best possible starting position: a settled drive and the full bandwidth to itself, without competition from other copies.

The order is the real trick. If the trigger file came up at the same time as the others again, it would block the drive at the same moment as the first time — and drag the bystanders down with it once more. Last and alone, it has the best chances.

ℹ️ How SynQaiPro identifies the trigger file
Not by which error was reported first — that would be misleading. The file that brings a drive to a halt often hangs in the waiting period for minutes, while copies started later on the already blocked disk fail immediately and thus report their error sooner. SynQaiPro therefore goes by which of the failed copies started first. That is the one that hung the longest — and therefore the actual cause.

During the retry the list shows exactly the affected files and nothing else, with the usual progress bars. Cancelling is possible at any time, including during the pause between the rounds. Whatever did not get its turn stays noted as pending — so the red button does not disappear while anything is outstanding. At the end the log reports either “✔ Retry finished — no more errors” or how many files are still left.

ℹ️ What you see during the pause
The trigger file is already in the list during those twenty seconds — without a progress bar, because nothing is being copied in that time, only waited for. So you see exactly what is coming next instead of sitting in front of an empty list and only guessing from the disabled button that anything is still to come. The status line counts the seconds down (“↻ Pause: 12 s to let the drive recover…”); the message goes into the log only once. At the top of the window the mint-green dot animation runs meanwhile — the same one that appears while waiting for the drives at the start of a synchronisation. It says: the program is working, it has not frozen. A bar in a row, by contrast, always means that this file is being copied right now.
⚠️ The button only applies to the synchronisation just finished
SynQaiPro deliberately keeps the failed files in memory only. Start a new analysis, delete the job or close the program and the list is gone, and the red button with it. That is not an oversight: the remembered rows refer to exactly the analysis state they came from, and would not be reliable afterwards. So use the button directly after the run — later the route is a fresh analysis again, which works just as well, only takes longer.
ℹ️ When the drive is not back at all yet
If not a single file gets through in the first round, SynQaiPro aborts the retry straight away instead of spending the waiting time and letting the second round run into nothing. The log then says that the drive is not ready yet. Nothing is lost — all files stay noted, the red button remains, and you can try again later.
Screenshot 17: After a synchronisation with errors: the red retry symbol ↻ with the count next to the anchor symbol above the comparison list
Fig. 17 — After a synchronisation with errors: the red retry symbol ↻ with the count next to the anchor symbol above the comparison list
💡 The recommended procedure after errors
First the retry button ↻ directly after the run — that is the shortest route, and most bystanders get through without further ado. If files are left over, start the analysis again and let the sync run a second time; that pass only covers the outstanding files. The most thorough attempt is the one after a PC restart: drive and Windows cache are then back in their initial state, and it becomes clear which files really have a problem. If the same files are still left after that, it is no longer chance: the medium can no longer read those spots. The log names them individually, so you can look for another source for exactly those files.
ℹ️ Several copy streams, several messages
When SynQaiPro works with several streams, every copy is monitored individually. So it can happen that one file is waiting while another next to it carries on normally — the speed display then shows progress although a waiting message is in the log. Both are correct; that is why every message names the file it is about.
Screenshot 18: Log during a waiting phase: “⌛ Waiting for drive” with a running seconds counter, below it the all-clear “▶ Drive is responding again” and a skipped entry
Fig. 18 — Log during a waiting phase: “⌛ Waiting for drive” with a running seconds counter, below it the all-clear “▶ Drive is responding again” and a skipped entry

4.6 Resuming cancelled copies

If a synchronisation is cancelled in the middle of a large file, SynQaiPro can save the part already copied and continue from that point on the next run instead of starting over. You recognise the switch by its colour:

  • Orange = ON: cancelled copies of large files are saved and continued on the next sync.
  • Neutral = OFF: a cancellation discards the copy state; the file starts from the beginning next time.

A resumable file carries a small resume badge in the list. The reset button (↺) discards saved partial copies.

ℹ️ Automatic behaviour on slow drives
If SynQaiPro detects a slow disk, it switches to a single copy stream (gentle mode) and resume is not available there — the switch is greyed out. The reason: the constant checkpoint I/O would slow the controller down. The synchronisation then runs safely with a single stream — much like Windows Explorer.

Lifting the block deliberately

This block applies as long as the automatic setting determines the number of copy streams. If you know better — because the disk was merely in a bad state during the test, say — set the drop-down from section 4.2 from A to 2x or higher. That discards the automatic classification and the resume switch can be used again.

Copy stream settingResume on a slow disk
A — automaticblocked (gentle mode)
1x — one streamblocked — 1× is gentle mode
2x16xavailable
⚠️ The safety net stays
If a copy stalls during the run anyway, the emergency brake engages regardless of your setting: SynQaiPro falls back to one stream and suspends resume. So a setting that is too high risks no data loss — at most a slower run.
💡 The emergency brake releases again
Such a hiccup is often just a snapshot in time — a full write cache, another program briefly getting in the way. If a series of files then runs through without trouble, SynQaiPro lifts the throttling by itself and returns to full speed; the log then shows “⚙ Drive has recovered — full parallelism reactivated”. Only if the hiccup repeats within the same run does it stay in gentle mode for good — then the disk really is overtaxed and not merely busy for a moment.
Screenshot 19: Resume switch (orange = ON) and a list row with the resume badge
Fig. 19 — Resume switch (orange = ON) and a list row with the resume badge

4.7 Cancelling

✕ Cancel stops the analysis or synchronisation at any time. Files already finished are kept; the file in progress is ended cleanly (and saved for the next run if resume is active).

While the cancellation runs, a notice overlays the view (“Preparing to cancel …”). If it drags on, the text names the drive being waited for — for example “Cancelling — waiting for drive S:\ …”. You can therefore see that the program is working and what it is waiting on.

ℹ️ Why cancelling sometimes takes a while
A write that the program has already handed to the drive cannot be recalled — it has to finish. On slow media that can take several seconds, especially while Windows is still flushing cached data. This is not a fault: the cancellation takes hold as soon as the running write returns. Wait for the notice rather than killing the program — otherwise partial copies are left behind untidied.
An unhandled error has occurred. Reload 🗙