Allway Sync is a file and folder synchronization manager. A job connects two or more locations, analyzes what changed since the previous run, then copies newer file versions and propagates selected deletions so the locations agree. Those locations can include local folders, network shares, removable drives, FTP or WebDAV servers, and supported online storage. Synchronization is different from a simple copy: a deletion or restored older document can become an intentional change that travels to the other side.
Jobs define partners
Each Allway Sync job stores its partner folders and direction rules. A two-way job accepts changes made on either side. A one-way job can act more like replication, while a multi-folder job keeps several locations in the relationship. Filters can exclude static or unwanted paths.
Choosing the wrong direction changes the meaning of the job. A one-way rule can replace destination changes with the source copy. A two-way rule can bring a deletion back to the main computer. Folder names alone are not enough when two external drives look alike, so checking the drive identity and path before analysis prevents a correct job from running against the wrong device.
Analyze before copying
The Analysis phase lists proposed copies, replacements, deletions, and unresolved items. Allway Sync lets the user change the direction for one row or a selected group before synchronization starts. Once copying begins, those choices lock until the next analysis.
This preview is the last clear chance to catch a mistaken deletion rule. A large list should not be approved only because most arrows point in the expected direction. Sorting or filtering for deletions and questionable files exposes the actions that can remove or replace data. A completed analysis does not modify the partner folders by itself.
History guides changes
Allway Sync keeps synchronization history in its own database so it does not rely only on the newest file timestamp. That history can recognize that an older document was deliberately restored and should travel to the other location. The hidden synchronization data also helps identify deletions.
The history must exist on the participating devices. A first run, a manually copied remote folder, or removed synchronization metadata leaves less context, so Allway Sync may mark files as questionable. Running the first synchronization through Allway Sync on each computer establishes that shared state. Deleting the hidden metadata because it looks unfamiliar can turn an ordinary next run into another first comparison.
Conflicts stop certainty
If the same file changes in several partner folders, Allway Sync cannot safely decide which content should win. It marks the item as questionable and asks for manual review or follows the configured error-handling rule. The choice replaces one whole file with another.
Allway Sync does not merge paragraphs, spreadsheet cells, database records, or messages inside two competing files. A mail archive or database is one synchronization unit even when many records sit inside it. Closing applications that keep such files open reduces the chance of copying a changing container. Copying locked files needs the required Windows services and administrator context.
Deletions travel
In normal synchronization, deleting a file from one partner can delete it from the others. This keeps mirrors consistent and is one of the main differences between sync and an append-only backup. Deletion propagation can be disabled when that behavior is not wanted.
A backup plan should keep independent history outside the active synchronization set. Otherwise an accidental deletion, encrypted file, or damaged document can spread as faithfully as a good edit. Allway Sync can support one-way backup jobs, but a bidirectional working folder should not be the only recovery copy.
Remote job limits
When a network transfer fails, Allway Sync writes to a temporary destination and replaces the target only after the copy completes. The interrupted file therefore does not automatically replace the good target. The transfer itself cannot resume from the broken point, so the next run must send that file again.
Very large jobs consume memory for every analyzed item and can exhaust a 32-bit process. Splitting static archives away from frequently changed folders reduces the working set, while a 64-bit installation can use more memory. Warnings can also pause a job until the user resolves them, so an unattended window that appears idle may be waiting for a conflict decision rather than copying slowly.
