Folder Sync

Folder Sync pushes a local folder to a server and sends only what changed. Instead of re-uploading everything, or answering a prompt for every file, ZestSSH compares both sides, shows you exactly what will happen, and then uploads just the new and changed files in one operation. It is a one-way mirror, from your device to the server, and it never changes anything on the server without showing you first.

Folder Sync is part of the desktop dual-pane file manager (Windows, macOS, Linux).

Starting a folder sync

Open the SFTP dual-pane view. Point one pane at the local folder you want to send and the other pane at the destination folder on the server.
Right-click empty space in the local pane and choose Sync folder to server.

ZestSSH scans both sides, reading each server folder once rather than checking every file individually, and opens a preview. Nothing is uploaded until you confirm.

The preview

The preview lists what the sync would do, grouped by outcome:

Changed: files that exist on both sides but differ. They will be replaced.
New: files that are not on the server yet. They will be created.
Unchanged: files already identical on the server. Nothing is sent for these.
Only on the server: files in the destination that do not exist locally. They are left alone unless you opt in to deleting them.

The confirm button reads Sync N files, where N is exactly the number of files that will be uploaded, plus any deletions you enabled. If there is nothing to send, the preview says Everything is already up to date and no transfer starts.

There are never per-file prompts during a folder sync. You make one decision, then the whole run goes through the normal transfer queue and Activity panel.

Preview only (dry run)

Choose Preview only to close the preview without sending anything. This is a dry run: you see every file the sync would upload, skip, or delete, and the server is untouched. Use it to check a deployment before committing to it.

How ZestSSH decides a file changed

ZestSSH checks the cheapest signal first and stops as soon as it has an answer:

Your last upload. ZestSSH keeps a small record on this device of each file it uploaded to that server folder, with the file’s size and modification time. A file that still matches its record was uploaded unchanged before, so it is skipped without contacting the server at all.
Size. If the local and server copies have different sizes, the file changed.
Modification time. Same size and a modification time within one second of the server copy means unchanged. ZestSSH sets the server copy’s timestamp to match the local file on every upload, so this compares against a value ZestSSH itself wrote, not the server’s clock.
Content, only when you turn on Verify by content (below).

The record from step 1 stays on this device only. It is not part of Cloud Sync and it is not included in .zest backups.

Verify by content

Timestamps can lie. If you restore a file from a backup, unzip an archive, check out an older branch, or edit a file and keep its old timestamp, the content changes but the modification time may not. A size-and-time comparison would call that file unchanged and skip it.

Turn on Verify by content in the preview to compare files by checksum instead. ZestSSH computes a SHA-256 checksum of the local file, asks the server for the checksum of its copy, and uploads only the files whose contents actually differ. The preview re-scans with the new setting, so the counts always match what the run will do.

This is slower than the default comparison because the server has to read every file, and it needs a shell on the server to compute the checksum. If the server cannot provide one, ZestSSH falls back to the size-and-time comparison for that file and says so in the file’s reason.

Force re-upload everything

Turn on Force re-upload everything in the preview to send every file, whether or not it looks unchanged. Use it when you suspect an earlier upload was corrupted or interrupted and you want a clean copy of the whole folder on the server.

Deleting files that only exist on the server

Files that exist in the destination but not in your local folder are shown under Only on the server and are never deleted automatically. To remove them, tick Also delete the files that only exist on the server in the preview. The files are listed by name, so you can see exactly what will go.

Deletions run last, only after every upload in the run has succeeded, so a failed upload never leaves the server missing a file it just deleted. Deleted files go through the same undo window as deleting files by hand in the SFTP browser. Folders on the server are never deleted by a sync.

Servers that do not allow timestamp changes

Some hardened or chrooted servers refuse to let a client change a file’s modification time. On those servers every uploaded file ends up stamped with the upload time, which would make every file look changed on the next sync.

ZestSSH checks whether its timestamp took after the first upload to a folder. If the server refused it, ZestSSH tells you once and compares files by size for that folder instead of re-uploading everything each time. For certainty on such a server, use Verify by content.

Not readable: folders and files the sync could not read

Folder Sync lists both sides before it plans anything, and a listing that fails is never treated as “nothing is there” in a way that could delete files. Three cases:

A local folder cannot be listed (no permission, or a dead junction or link). The preview warns “Could not read <path>. Nothing under it was synced, and nothing under it on the server was touched.” The folder is skipped whole: nothing beneath it is uploaded, and nothing beneath its server counterpart is planned for deletion, because an unreadable folder must never be mistaken for an empty one. Fix the local permissions and open the preview again.
A server folder cannot be listed (the user you connected as has no read permission on it, or it does not exist yet). ZestSSH treats it as empty. That can only make files look new, so at worst they are uploaded again; a failed server listing never causes a deletion.
A server file has no modification time (the server returned no stat attributes for it, the same condition the overwrite dialog shows as Not readable). Such a file is never counted as identical by the size-and-time comparison; the safe direction is to upload it again. Turn on Verify by content to compare checksums instead, or fix the read permission on the server.

All three are conditions on the server or the local disk, not settings in ZestSSH. See the SFTP Browser page for what Not readable means in the overwrite dialog and which buttons it disables.

Accented names and mixed case

macOS and Linux can store a filename like café.txt in two different byte forms that look identical. ZestSSH normalises names for comparison, so a file created on a Mac re-syncs to a Linux server as unchanged instead of being uploaded again every time. The name written to the server is always the original one.

Windows and macOS treat README.md and readme.md as the same file, while a Linux server can hold both. If a server folder contains such a pair, ZestSSH cannot tell which one your local file matches, so it skips both, warns you, and names the two files. Nothing is overwritten by guessing.

Limits

A sync covers up to 100,000 items. Above that, ZestSSH stops and asks you to sync a smaller folder rather than run a partial sync.
Sync is one-way, from your device to the server. Files changed on the server are not pulled back; a changed server file shows as Changed and is replaced on the next sync.
Hidden files (names starting with .) are included.

Uploading over an existing file

Folder Sync is for whole folders. When you drag a single file, or a folder, onto a location where a file of the same name already exists, ZestSSH asks once how to handle it and lets you apply the same answer to the rest of the batch:

Replace changed files: replace it. Files that are already identical (same size and modification time, or the same checksum when only the modification time differs) were skipped before the prompt, so this only ever replaces real changes.
Replace only when local is newer: replace it only if your copy has a newer timestamp. A file that differs but has an older timestamp is not sent silently: when the batch finishes, ZestSSH tells you how many such files it held back and offers Send them anyway.
Skip existing files: leave the server copy as it is.
Keep both: upload under a new name such as report (1).pdf.

Files that do not exist on the server yet are always uploaded, whatever you chose for the conflicts.

Questions about what gets sent

How do I upload only the changed files in a folder? Use Folder Sync: right-click empty space in the local pane and choose Sync folder to server. The preview shows what changed, and only those files are sent.
Does ZestSSH skip files that are already on the server? Yes. A file with the same size and modification time as the server copy is skipped, both in Folder Sync and when you drag a folder across.
Can I mirror a local folder to the server? Folder Sync is a one-way mirror from your device to the server. It never pulls changes back down.
Is there a dry run? Yes: Preview only. It shows the full plan and sends nothing.

Questions about deleting, forcing and timestamps

Can it delete files on the server that I deleted locally? Only if you tick the delete option in the preview. The files are listed by name, they are removed only after every upload succeeded, and the deletion waits in the usual hold window where you can undo it.
What happened to Replace if newer? It is now called Replace only when local is newer, and it reports the files it held back instead of skipping them silently.
How do I force everything to re-upload? Tick Force re-upload everything in the preview.
Why does every file show as changed on every sync? Usually the server does not let ZestSSH set file timestamps. ZestSSH detects that, tells you once, and switches that folder to comparing by size. Turn on Verify by content to compare by checksum instead.