Skip to content
English
Submit a Support Ticket
Contact us
  • There are no suggestions because the search field is empty.

SureSync MFT Internal Build

An MFT Internal Build is used to update your MFT environment with the latest fixes not yet available in an official public release.

SureSync MFT Installer

The full SureSync MFT Internal Build can be downloaded by clicking here.

File Name: SureSyncMFTSetup.exe

Version 2.0.31.08

To update to the internal build, simply run the installer on each machine in the environment with the Hub or the Communications Agent installed. The steps are the same as performing a regular SureSync MFT Update as outlined in the Updating SureSync MFT KB article.

Fixes in the 2.0.31 Internal Builds

2.0.31.08

  • The create jobs from template functionality was not working correctly. This has been fixed in 2.0.31.8.
  • The Detailed Status panel was not always clear refreshing the lock list if it was left displayed. This could result in locks being in the list that were not truly locked anymore. This has been fixed in 2.0.31.8.

2.0.31.07

  • In some folder delete scenarios, a deadlock could occur that would block journal event processing. This has been fixed in 2.0.31.7.
  • An internal NullReferenceException could be thrown when trying to queue a scan retry for an item where its history was deleted. This has been fixed in 2.0.31.7.
  • If a Job is added to an environment that references an exact same root path that is referenced in another Job, the Root Group in the database is shared. This is wanted behavior for performance. However, there was an error in the processing logic where the new job marked the Root Group as needing a draining operation that would not be signaled as complete. This would block processing from the other already existing Job. This is most likely to occur in a scenario where a synchronization Job already exists and a 2nd Job is creating doing archiving of a path in the synchronization Job. This has been fixed in 2.0.31.7.

2.0.31.06

  • Performance optimizations have been made to Change Journal processing during job initialization and in path loss scenarios when many Jobs had root paths on the same volume. This situation would cause excessive processing and significantly slow processing. This has been fixed in 2.0.31.6
  • In a heavy-load situation, creating many new files could result in locks that are not released. This has bene fixed in 2.0.31.6.
  • In rare timing circumstances, a path drop could cause a path to trigger a full rescan. This has been fixed in 2.0.31.6.
  • A test from the MFT Desktop would not always correctly identify a workstation license.  This has been fixed in 2.0.31.6.

2.0.31.05

  • A deadlock could occur between a folder scan and journal events on the same folder.  This has been fixed in 2.0.31.5.

2.0.31.04

  • A state instance checkpoint could roll back, causing the same events to be reprocessed multiple times. This condition would eventually clear, but the volume of work could cause significant delays.  This has been fixed in 2.0.31.4.
  • A server could incorrectly signal that its change journal needed draining. The draining process would block scans and actions unnecessarily. The problem signal was intended only to be used on the initial startup of a job. This has been fixed in 2.0.31.4.

2.0.31.03

  • When performing a full scan, an internal throttle could prevent state scans from executing for a period of time, slowing the process of files starting to synchronize. This has been fixed in 2.0.31.3.
  • Alerts were not being sent when defined. This has been fixed in 2.031.3.
  • If a folder truncate delete finds files or subfolder contents dated later than the folder date, scan retries were being performed. This could generate a lot of extra scanning that is not necessary, sometimes preventing the folder from every being deleted. This has been fixed in 2.0.31.3
  • There were situations where folder scans could block state scans. This has been fixed in 2.0.31.3.
  • A correction has been made to the Hub to correct problem event dates. This has been fixed in 2.0.31.3.

2.0.31.02

  • A "Foreign Key Constraint" error could occur. An additional fix has been made to prevent these from occurring. This has been fixed in 2.0.31.2.
  • A deadlock could occur, which would halt processing. This has been fixed in 2.0.31.2.
  • The default for root group creation has been changed to have each root path use its own root group unless the root path is identical across multiple overlapping jobs. This has been fixed in 2.0.31.2.
  • An alert may be incorrectly generated if a source path is excluded by rule. This has been fixed in 2.0.31.2.

2.0.31.01

  • A "Foreign Key Constraint" error could occur during a cleanup process that could cause the Hub service to be stopped. This has been fixed in 2.0.31.1.
  • A change has been made to help prevent an incorrect rollback of a file to an older version. There are situations where you want an older version to be synchronized. For example, if a file is synchronized across locations and an old version is added to one path as a restore operation, you want that action to be synchronized to the other sides. A new program (MFTDiagnostics.exe) can be launched from C:\Program Files (x86)\Software Pursuits\SureSync MFT and run against the MFT database to produce a report of potential rollbacks. This has been fixed in 2.0.31.1.
  • An option has been added to recreate a root path into its own root group. When you do this, a recan will be required to rebuild history. Details of the issue can be found in the following KB: https://support.softwarepursuits.com/mft-root-groups. The option to force a root path can be found on the General tab of a root path. This has been fixed in 2.0.31.1.