Sharing from a sync folder

Syncing keeps your machines the same. Publishing shows somebody something. They are not the same job.

A sync folder solves a real problem well: the same files, current, on every machine that needs them. Delivery is a different problem.

A sync folder for working files beside a published address for finished ones.
A sync folder for working files beside a published address for finished ones.

Two different jobs

Syncing. Your laptop, your desktop and a colleague's machine hold the same current files. Changes propagate. Work in progress stays in one place and nobody mails versions around.

Publishing. Somebody outside opens something and reads it. They do not need the file, they need the content, and they will do it on whatever device is nearest.

Using the sync folder for the second produces the friction people associate with it.

Situation Route
Files you are working on Sync folder
A colleague editing with you Sync folder
Large assets in progress Sync folder
A brochure for a customer Published address
A quote for a client Published address
Anything read on a phone Published address

What the recipient sees

A file viewer with the service's branding, a download button, and usually an invitation to create an account.

That frame belongs to the storage service. Your document is a panel inside somebody else's product, which is a strange way to present a proposal or a brochure.

Compare with an address on your own domain, where the document is the page.

The settings worth checking

Expiry. Some plans let you, or a team admin, set an expiry date on links. A link that dies after a month is fine for a file transfer and wrong for anything printed or filed.

Downloads. Whether the recipient can take a copy. Sometimes you want that and sometimes you very much do not.

Access without an account. Test it in a private window, which is not signed in. You are always signed in, so you can never see what a recipient sees from your own browser.

This one catches people badly.

In Dropbox, moving or renaming a shared file keeps the link working. Deleting it, or replacing it with a new file under a new link, is what leaves the people holding the old link with an error.

If a link has been sent to a client, keep the file it points at in place rather than deleting and re-uploading it, or send a published address instead.

The arrangement that works

Working files in the sync folder, where they belong.

Finished things at an address, published, where they open on any device, cannot be broken by tidying, and carry your name rather than a storage service's.

Closely related: A Dropbox alternative for sharing, and Sharing a file from cloud storage for the adjacent problem.

Put it at an address

Keep working files in the sync folder, publish anything meant to be read, check expiry and download settings, avoid deleting shared files, and test every link in a private window.

Questions people ask

What is a sync folder actually for?

Keeping the same files on several machines and letting collaborators work on them. It is a working folder, not a delivery mechanism.

Why does a shared link feel awkward?

The recipient lands in a file viewer with a download button and an invitation to sign up. That frame is the service, not your document.

What should I check before sending one?

Whether the link expires, whether it allows downloads, and whether it works for somebody with no account.

What happens when I reorganise?

In Dropbox, moving or renaming a file inside your Dropbox keeps the shared link working. Deleting the file or turning the link off does break it.

What is the alternative?

For anything that is read rather than worked on, publish it at an address. Keep the sync folder for files in progress.

Keep reading