Overwrite Modes

Overwrite Modes

Every task has an overwrite mode (set via the radio buttons above the TRANSFER button):

Mode	Behavior
Replace (default)	Always sends the file, overwriting whatever's at the destination. No existence/modified-time check is done — this is the fastest mode.
Replace if newer	Sends the file only if it doesn't exist yet at the destination, or the source is newer than what's there. Skips the file otherwise.
Don't replace	Sends the file only if it doesn't already exist at the destination. If it exists, it's always skipped (regardless of which one is newer).

Skipped files don't show up in the transfer queue at all — they're decided before the queue is built, so the queue only ever shows files that are actually being sent.

How "does it exist / is it newer" is decided

• Local destinations: a plain filesystem check (File.Exists / last-write-time comparison) — effectively instant, no network involved.
• FTP/FTPS and SFTP destinations: the app needs to ask the server. As of v3.3.2, it does this efficiently:
  1. For each destination that needs checking (i.e. mode is Replace if newer or Don't replace), the app opens one connection and lists every distinct remote subfolder that the task's files will land in (usually just one folder, unless Keep folder name or several destination subfolders are in play).
  2. That listing (file names + modified times) is cached in memory.
  3. Every file's exists/modified-time question is then answered from that in-memory cache — with zero extra network round-trips per file.
  4. Only once all of that is settled does the actual upload phase begin.

Before v3.3.2, each file's check opened its own fresh connection (and on FTP servers where the MDTM command doesn't actually work despite being advertised — see FTP, FTPS and SFTP — a broken time-check could cost two connections per file). For a task with many files in Replace if newer mode, that added up to a very visible delay before anything started uploading, compared to other FTP clients that don't reconnect per file. If you're on an older build and a transfer feels like it's "scanning everything first" before sending, updating to v3.3.2 or later fixes exactly that.

Choosing a mode

• Use Replace for anything where you always want the latest version pushed, no questions asked (e.g. a build output you rebuild every time) — it's also the fastest mode since it skips the existence check entirely.
• Use Replace if newer for one-way sync scenarios where you don't want to re-send files that haven't changed.
• Use Don't replace to seed a destination once without ever touching files that are already there, even if your local copy changed since.