WinSCP

Moving files to a server is a solved problem, and the reason one client became the default on this platform is not the transferring. WinSCP does that competently across the secure protocols and several others, and what keeps people using it is a watching feature that turns a remote folder into something close to a local one.

WinSCP shows two panes, local on the left and remote on the right, in the arrangement file managers have used for decades. A single-pane arrangement is available for anybody who prefers it.

Underneath sit scripting, automation, plus a set of synchronisation behaviours that repay understanding, because the differences between them decide whether files get copied or deleted.

The watcher that makes remote feel local

Here is the WinSCP capability the documentation itself describes as unique, and it is the reason the software outlasted its rivals.

Point it at a local folder and a remote one, and it registers with the system to be told whenever anything in the local folder changes. Save a file in whatever editor you normally use, and the change appears on the server without you doing anything.

The practical effect is working on remote files with local tools. Your editor, your search, your version control, all operating on files that happen to be mirrored somewhere else moments after you save.

That is what replaces the commercial tools that map a remote folder to a drive letter, and it does it without a driver or anything installed at a low level.

One detail of the mechanism explains a common confusion. The system tells it that something in the folder changed, not what changed, so it then compares to work out what to send. That is why you see it report a change and then do nothing, which confuses people who expect one to mean the other.

It only watches in one direction

The WinSCP asymmetry nobody mentions, and it decides whether this fits your situation.

Watching works because the system can report changes in a local folder. No file transfer protocol offers the equivalent for a remote folder, so there is no way to be told when something changes on the server.

The consequence is that keeping a local folder current with a remote one cannot work the same way. Instead it means running a full comparison on a timer, which the software provides as a bundled extension rather than as a built-in watcher.

So the two directions are entirely different features. Local to remote is instant and event-driven, and remote to local is periodic and checks everything each time.

Anybody expecting symmetric behaviour will be disappointed by the second, and the disappointment is with the protocols rather than with the software.

For synchronising folders between machines you control, where both ends can watch, a peer-to-peer tool that keeps folders matched in both directions does that continuously.

Why it uploads everything on every change

The WinSCP failure people report most often, and the cause is a precondition nobody reads.

The complaint is consistent. Somebody enables the watcher, changes one file, and the whole directory uploads. They check the options, find nothing enabling that, and conclude it is broken.

The answer from the maintainer is that the watcher has to be started on folders that are already synchronised. It compares before sending, so if the two sides differ substantially at the moment you start, the comparison finds a great deal to send and sends it.

Running a full synchronisation once, deliberately, before starting the watcher removes the problem entirely. After that the comparison finds one changed file and sends one changed file.

That is the whole fix, and it explains a complaint that otherwise looks like a bug.

The delete option, and the warning attached to it

Being direct about the WinSCP setting that removes data, since the documentation itself pauses to warn about it.

Synchronisation can be told to delete on the receiving side anything that no longer exists on the sending side. That makes the two actually match rather than merely accumulating.

The documentation’s own instruction is to learn how it works before enabling it, which is unusually candid for a product manual and reflects what happens when people do not.

The danger is the same one that catches people with any tool of this class. A copy adds, and a synchronisation with deletion enabled makes one side match the other, so pointing it the wrong way empties the side you meant to protect.

Read the direction in the dialog every time rather than trusting the last configuration, particularly if you use both directions for different jobs.

When synchronisation refuses to work properly

Two WinSCP diagnostic points from the maker’s own answers, and both are obscure enough to waste an evening.

Timestamps are how it decides what is newer. Over the secure protocols that works, and over plain file transfer and web-based protocols the server may not preserve the timestamp of an uploaded file, which limits local to remote synchronisation because the comparison has nothing reliable to compare.

The second is a combination that quietly misbehaves. Choosing size as the criterion while transfer runs in text mode produces inconsistent results, because text mode can change the file’s size in transit through line ending conversion, so the sizes legitimately differ after a correct transfer.

Neither produces a useful error. Both produce a synchronisation that keeps transferring things it should not, or skipping things it should.

The protocol you choose is the security decision

This deserves stating plainly, because the WinSCP name misleads people.

The software speaks the secure protocols and it also speaks plain file transfer. Choosing the plain one means the password and the file contents travel unprotected, and the client will do it without complaint because you asked.

Nothing about the tool makes a plain connection secure. The name refers to what it was built for rather than to what every session does, and the protocol chosen in the login dialog is what actually decides.

Where the server offers both, choose the secure one. Where it offers only the plain one, know what that means before sending credentials over it.

Automation, and the terminal alongside

Beyond the interface, the whole of WinSCP scripts.

Transfers, synchronisations, directory operations can all be driven from the command line or from a script file, which is how people schedule an overnight upload or wire a transfer into a deployment routine. A programming interface exists for calling it from code rather than from a shell.

There is also an integrated editor, so a remote file opens, edits and saves back without a manual download and upload around it.

And the terminal side is a click away, since a session can hand off to a terminal client for the same host with the credentials already known. PuTTY is what it hands off to, and having both means moving between transferring files and running commands without reconnecting.

Stored sessions and the password question

WinSCP saves sessions with their settings, and optionally with their credentials, which is convenient and worth a moment’s thought.

Stored passwords sit protected on the machine, and a master password can be set so they are not usable by anybody who simply opens the program. Without that, somebody with access to your logged-in session has your servers.

The considered arrangement on a shared or portable machine is storing the host and settings but not the password, which loses a little convenience and keeps the credentials in your head where they cannot be copied off with a folder.

For organising many connections into a tree with inherited settings rather than a flat session list, mRemoteNG handles that across protocols.

Conclusion

WinSCP earned its position through the watching feature rather than the transferring. Editing files with your own tools while they appear on a server moments later is a properly different way of working, and it needs nothing installed at a low level to achieve it.

Learn three things before relying on it. Start the watcher on folders that already match, or it will send everything. Read the direction before enabling deletion, because synchronisation removes as readily as it adds. And check which protocol the session actually uses, since the secure ones are a choice rather than a guarantee the name provides.