File Sharing Software: What to Test Before You Buy

If you are new to this category, the confusing part is that one product is sold as the answer to three different problems. "File sharing software" can mean keeping files available on all your devices, sending a document to someone outside your organization, or storing everything the business has ever produced somewhere safe.

Those are three jobs. Products are good at different ones. Knowing which job you are buying for is most of the decision.

Most business file sharing software shortlists come down to the same names: Dropbox, Box, Google Drive (Google Workspace), Microsoft OneDrive and SharePoint, Egnyte, and Citrix ShareFile. All of them sync competently, and the difference most buyers end up living with is how each one's permission model behaves under the tests below.

What to take away

Three jobs, one product

Sync keeps a copy of files on your machine and on the provider's servers, and reconciles them. It is what makes your laptop, your phone, and your colleague's desktop show the same folder. Sync is the feature that generates the most day-to-day trouble, because it is the one doing something genuinely difficult.

Share hands access to a specific file or folder to a specific person, or to anyone holding a link. This is where the security decisions live.

Store is the long-term home for material that is not being actively worked on. Archives, records, finished work. Storage cares about durability, retention, and cost, and barely about convenience.

A product that syncs beautifully may have a crude permission model. A product with excellent governance may have a sync client that annoys everyone. Decide which of the three matters most to you before you look at anything, because the marketing will not distinguish them.

The permission model is the product

For business use, this is the part that actually differs, and it is worth learning the vocabulary because vendors use the same words to mean different things.

Inheritance. Whether a file's access comes from the folder it sits in. Almost always yes, and the interesting question is what happens when you move a file. Does it keep the access it had, or take on the access of its new location? Both designs exist. Both surprise people.

Named access versus link access. Named access means a specific account can open it. Link access means possession of the URL is the credential. Link access is enormously convenient and it is the mechanism behind most accidental exposure in this category.

Link scope. A link can be open to anyone, restricted to people inside your organization, or restricted to named recipients who must sign in. Find out what the default is when someone clicks "share", because that default is what your organization will mostly do.

Expiry and passwords on links. Whether links can be time-limited, and whether that can be enforced as a policy rather than left to each person's judgment.

View versus edit versus download. Preventing download is a weaker control than it sounds, anyone who can see something can photograph it, but it does stop casual copying and it does keep files out of other people's storage.

External and guest access. Whether people outside your organization can be granted access at all, whether they need an account, and whether an administrator can see and revoke all such access from one place.

The single most useful question to ask of any candidate: can an administrator produce a list of everything currently shared outside the organization? If the answer is no, you cannot govern it, no matter what the settings screen offers.

If you find yourself arguing about whether access should follow folders, groups, or properties of the person, it is worth knowing that this is an old and well mapped argument. NIST Special Publication 800-162, Guide to Attribute Based Access Control (ABAC) Definition and Considerations, sets out what each model buys and what it costs to reason about, which is useful vocabulary to take into a demonstration.

Links have an afterlife

A share link, once created, tends to outlive everything about the situation that produced it.

Two consequences worth planning for. Set a sharing default that is restrictive and let people loosen it deliberately, because the reverse, a permissive default that people are supposed to tighten, does not happen. And schedule a review of external shares, because it is the only thing that removes the ones nobody remembers.

What the sync client does when things go wrong

Sync is easy when everything works. Evaluate it on its failure behavior instead.

Conflicts. Two people edit the same file offline. Almost every product resolves this by keeping both and renaming one. Find out how it names the copy and whether anyone is told. The failure mode is silent: someone's work is preserved in a file nobody opens.

Deletion. Deleting a synced file deletes it everywhere, including from colleagues' machines. This is correct behavior and it consistently shocks people. Know where deleted files go, how long they stay, and who can retrieve them.

Selective and on-demand sync. Whether you can choose which folders come down, and whether files can appear in your file browser without occupying disk space until opened. For anyone with a small drive and a large shared archive, this is not optional.

Bulk operations. What happens when someone drags a very large folder, or when a script writes thousands of files. Sync clients can saturate a connection or fall a long way behind, and a client that is silently behind is worse than one that stops with an error.

Filenames. Different systems disagree about which characters are permitted, how long a path may be, and whether upper and lower case are distinct. Files that break these rules get renamed, skipped, or refused. If your work involves long folder hierarchies or names generated by another system, test this deliberately.

Files that do not merge. Design files, drawings, and most binary formats cannot be merged. If two people edit one, someone's work is discarded. Products differ in whether they offer a check-out mechanism to prevent this. If your team works with such files, this is a top-tier requirement rather than a detail.

Versioning and the recovery question

Version history is the feature people assume they have and rarely test.

Ask three things:

Folder level answers matter because the realistic bad day is not a mistake. It is mass encryption arriving through a sync client from somebody's laptop.

Recovery at that scale is a storage capability, not a security one. The plain description of how these incidents unfold in the CISA StopRansomware Guide is a better test spec than any feature list.

Test the third one during a trial. Delete a populated folder, restore it, and check whether the sharing permissions came back with the contents. Very often they do not, and rebuilding permissions across a restored archive is a substantial job.

How storage is counted

Get this straight before comparing prices:

Get these answers in writing before you compare quotes.

A trial that tells you something

Skip the sample files. Do this instead:

Getting your files back out

Ask before you commit:

Check your own retention schedule first: what you must keep, and for how long, is set by your obligations rather than by the vendor.

What does not move with you

Files move. The things that do not move are:

Which is why the questions above are worth asking in the first week of an evaluation rather than the last week of a contract.

Where to read next

Three neighboring decisions overlap with this one, and most suites include storage, so the suite decision may already have made part of this choice.

People paste files into conversations regardless of policy, so the collaboration decision is part of your storage decision. Mail attachments are also storage, which brings in the mail decision and hosting arrangement.

Common questions

Should we keep a file server as well?

Sometimes, and the honest reasons are specific: very large files edited in place, an application that expects a network path, or a regulatory position on where data sits. Keeping one for comfort is expensive, because you end up maintaining two places and a convention nobody follows.

How do we stop people sharing things with open links?

Change the default rather than the culture. If the share dialog opens on the narrowest option, most people accept it. Policy documents about link hygiene have almost no effect compared with what the button does when clicked.

What is a reasonable retention period for deleted files?

Set a floor that survives somebody's holiday — thirty days at minimum — and longer where the material carries an obligation. What matters more than the exact number is knowing what it is, and whether an administrator can reach further back than a user can. Treat a vendor's default as a starting point to change rather than as your policy.

Do we need to classify our files?

A light scheme you will maintain beats a detailed one you will not. Two or three levels, applied at the folder level rather than the file level, is usually the most any organization sustains without a dedicated person.

Further reading: Restore a previous version of a file stored in OneDrive (support.microsoft.com).