The long awaited 2.0 file and folder locking release is nearing launch and we want to thank everyone for their patience during the past months as the feature was developed. We are now wrapping up the last of our testing and aim to release it starting Monday 30th June 2014

Why did development take so long?

File and folder locking was not a trivial feature to build and the primary reasons around the delays in testing and development were due to enforcement of locks on the client-side.

Locks must be enforced across all clients that Nimbox supports, including the desktop client, the web interface, WebDAV, the Outlook plugin, and our mobile apps. As a result, lock enforcement and error responses had to be developed for each of these clients, requiring changes across many different code paths.

Enforcement on the desktop client was tough to get right since users can potentially place locks on any file or at any folder level within a Team Share. Our first major challenge came after we developed the architecture for the enforcement on the desktop client, which uses a ‘soft lock’ mechanism that does the following:

1. Displays a lock icon on locked files and folders,
2. Allows LOCAL changes to locked files and folders BUT,
3. Notifies users when they have modified a locked file or folder outside of their scope AND,
4. Prevents those local changes to locked files from syncing up until the lock is removed.

This soft lock method was chosen because the obvious options for placing hard(er) locks on the filesystems hosting the sync client were either highly ineffectual (e.g. setting the read only flag still allows moves, renames, and deletes) or overkill (e.g. placing an open handle on a file to prevent changes consumes system resources and doesn’t scale well for folders with thousands of nested files). Also, soft locks allow Nimbox to quickly and elegantly handle any number of files and folders across both OSX and Windows.

Our initial testing with this implementation (which started in November 2013) worked great, until we realised that it would not work with many customer implementations of the file server enablement feature.

For those who are not familiar, our file server enablement feature is among one of the most utilised features in Nimbox Vault and allows our users to overlay the powerful features of Nimbox’s cloud technology onto their in-house file servers. By giving administrators the ability to map existing directory structures on a file server directly to folders within Nimbox Vault, we provide users the freedom to sync and use their mobile devices to access this file server data, whilst still providing local end-users access to the file server via network mapped drive is they are working in the office.

The challenge that this feature posed to file locking was that network mapped drives are not powered by clients that we control (i.e. they are usually Windows network mapped drives), which means that we had no way of notifying mapped drive users that a remote file was locked or that their changes were not syncing up. Since these users are unable to receive overlays or systray notifications, our lock enforcement had to be re-engineered to allow mapped drives to recognise that a file was not updatable (i.e. locked).

Considering our previous options (read only, open handles), building enforcement for this on OSX and NTFS filesystems required a complete rethink. After much testing, we determined that we could accomplish enforcement for file server enablement and mapped drive scenarios by setting filesystem level permissions in such a way that was strong enough to be effective without being so strong that it consumed resources or prevented access to business critical files in the case a lock was set accidentally or wasn’t properly removed. This took a lot of testing to make sure that we weren’t overwriting existing permissions or setting permissions that could potentially remove access from admins who needed to be able to make changes to the data. So, we ended up allowing admins to specify extensions that they would like ‘hard locks’ placed on via a company policy.

On Windows, hard locks are implemented by setting the following DENY ACE for the EVERYONE SID:

• Create files/write data
• Create folders/append data
• Write attributes
• Write extended attributes
• Delete

On OSX, we set the UF_IMMUTABLE flag (essentially user lock).

These permissions still allow admins to modify files, but prevent non-admins from doing so, which works great for file server enabled environment’s. We can easily target these permissions via a unique ID and remove them once the lock is removed.

How will file locking work?

As you may have gathered from the above, Nimbox’s locking feature allows users to place locks on any file or folder within a Team Share, thereby preventing updates to those resources from all other users. Users who placed these locks will still be able to make updates to the files or folders.

Below are important additional points:

• File locking will be disabled at the org level by default but, once enabled, will allow all users within an organisation to place locks
• Admins can remove locks from any user at any time
• Locks can be placed and removed via the desktop sync client or web interface
• Locks are ‘soft’ by default in that Nimbox will still allow local changes/deletes/renames by other users, but will prevent those changes from being synced up and will notify users via an exclamation mark icon overlay and a systray notification
• ‘Hard’ locks (which are enforced by the manipulation of filesystem level permissions) can be activated by entering specific extensions at the org policy level, e.g. “only enforce locks via filesystem permissions for .pdf, docx, xlsx, etc”
• Auto-locking will work for Excel and Word documents since Office makes it fairly easy to detect the filesystem events when one of their files is opened. Users will be prompted once and are able to choose whether or not they want to be asked again.

What other features will be included 2.0?

Release notes will soon follow, but we’ve got a few additional great features that will be included in 2.0:

• Download folder as a Zip archive via the web
• Upload a folder via the web via drag and drop onto the upload form
• Enable manual collision resolution (i.e. no user action dialog)
• Rollback all files within a root or folder back to a sepcific date – great for Cryptolocker

In closing

We know that this release has been a long time coming and hope that the value it delivers will soon overshadow the memories of the wait. I would love to hear your feedback on our proposed implementation and thank all of those who have commented on the community with their ideas, questions and concerns.

Until next time,
Tom,
Co-founder, Nimbox