ndSync for Windows 2.3.4 Update Notes



What's New in ndSync for Windows

ndSync for Windows version 2.3.4 includes bug fixes, code refactoring and performance enhancements. For example, documents are now uploaded and downloaded using multiple threads.

In addition, these specific changes have been made:

Support for Windows 10 Long File Paths

One limitation of ndSync for Windows (but not for ndSync for Mac) was the inability to sync content from the server to the user’s computer if the total path length of the content exceeded ~260 characters, the maximum path length that has historically been supported by Windows.  (The 260-character calculation includes the portion of the path dedicated to ndSync itself, such as:  “C:\Users\[username]\ndSync”.)

In 2016, Microsoft introduced a new feature in Windows 10 that permits (essentially) unlimited file paths.  ndSync for Windows v2.3.4 supports this feature.

First, it is necessary to enable this feature in Windows 10.  There are at least two ways to do so, but we suggest working with your IT Department before making this change.  This article describes the two methods:  using either the Registry Editor or the Local Group Policy Editor.

ndSync v2.3.4 will automatically detect when the Windows 10 Long File Path feature has been enabled.  No setting is required to be changed within ndSync.  If long file paths do not appear to be supported after installing ndSync v2.3.4 and enabling Windows 10 Long File Paths, make sure the feature has in fact been enabled by manually creating a long file path on your computer and, if necessary, restart your computer.

Support for Moving Documents and Folders

In previous versions of ndSync, if a user moved content from one synced location to another synced location on their computer, on the server this move was treated as two separate actions:  (1) the original moved content would be deleted and (2) the content in the destination location would be added as new content.  As a result, moving synced content was discouraged.

For example, if “Agreement.docx” (DocID 1234-5678-9012) was moved from the “Correspondence” folder to the “Agreements” folder, then the document with DocID 1234-5678-9012 would be deleted from the server and a completely new document (“Agreement.docx”) with a new DocID would be added to the server in the Agreements folder.  In the case where the user did not have the right to delete the original document on the server, the original document would be restored back to its original location AND a copy of that document would added to the destination it had been moved to as a new document.

Starting with v2.3.4, moving content between synced locations will now be respected on the server side, where it will also be treated as a move, not as a deletion and add, and therefore users are encouraged to move synced documents.  But a user will still need sufficient rights on the server to move any synced content, and if the user lacks those rights, then ndSync will revert the move, restoring the content to the original location and removing it from the intended synced destination.  Moving content out of the ndSync folder will also be rejected and reverted, as that would be treated as an attempt to delete the moved content, but a copy of the content will still remain in the destination. 

Restrictions on Deleting Synced Content

Users may inadvertently delete synced content in the mistaken belief that the deletion will simply unsync the content, when in reality that deletion will be propagated to the server.  Out of an abundance of caution, and based on feedback from clients, we have added restrictions on the ability of users to delete synced content and have those deletions propagated to the server.

Starting with v2.3.4, if a user needs to delete synced content and have that deletion propagate to the server, there will be only one way this can be accomplished, by using the ndSync actions -> Delete context action:


Selecting the Delete action will trigger a confirmation prompt:


Note that deleting content using the ndSync Delete action will permanently delete the content from the user’s computer, but on the server the content will only be added to the recycling bin.

Other methods of deleting synced content from the user’s computer will not be propagated to the server, including using the native Windows Delete action, dragging and dropping synced content to another location, cutting and pasting content, or any similar action.  ndSync will not propagate those deletions to the server and instead will restore the deleted content from the server to the user's computer.  In that case, the following notification will be displayed, explaining how the user can properly delete the synced content:


Because deletions of synced content can only be accomplished using the ndSync Delete action, the Delete action has been enhanced in two ways:

  1. It is now possible to select multiple synced documents to be deleted at the same time. (Previously, only a single synced document could be deleted at a time.)
  2. Individual folders may now be deleted. (Previously, the Delete action was not available for synced folders.)

Notwithstanding this new feature, a user’s ability to delete synced content remains subject to the user having sufficient access rights to the synced content (i.e., VESA rights).  Even if a user takes the appropriate steps to delete synced content, the deletion will not succeed if the user lacks appropriate rights to do so on the server.  In that case, the deleted content will be restored to the user's computer from the server.

Maximum Number of Documents Indicator

If a synced container has the maximum number of documents that can be synced (5,000), then a synced overlay icon with an exclamation point is shown on the container:


Unofficial Versions

In previous releases, if a synced document had been edited locally and while being saved to the server it was determined that the copy of the document on the server had already been modified or was checked out, then ndSync would save the locally edited document as an unofficial version on the server and future edits would be saved to that unofficial version.  That way, no data was lost.  When the locally edited document was closed, ndSync would restore the official version of the document from the server to the user’s computer.  The unofficial version would therefore only exist on the server.  Starting in v2.3.4, when the locally edited document is closed, the unofficial version will also remain on the user’s computer, but it will be renamed to indicate that it is the unofficial version and the unsynced overlay icon will be added.  For example:
The official version will still be synced down from the server to the local device.  Future changes made to the local, unofficial version will not be synced to the server.

Empty Documents

Empty (aka, zero-byte) documents that are created locally will not be synced to the server.

Adding Content to Unsynced Containers

The user will receive a warning if they attempt to add content (a document or subfolder) to a container that is part of the ndSync folder tree but where the container itself has not been synced (such as if it is an ancestor of a synced container). 


Back to Top

Was this article helpful?
0 out of 0 found this helpful
Powered by Zendesk