File sharing

The owner can revoke the grant. Recipients open the same object rather than each holding an independent copy they control. File transfer is the other pattern: a copy lands somewhere else, and the sender's later delete does not reach it.

Products use sharing for both, which is why handoffs fail. A "share" dialog that creates a public link to an object in the sender's account is sharing until the recipient downloads. After the download, a copy exists that revocation will not erase. A "share" that attaches the file to email was a transfer from the start. WebDAV, RFC 4918, is the protocol shape of real sharing: list, lock, read, write, on a collection the server keeps.

A producer drops a 2 GB cut in a team folder and invites the editor. Both open the same key. The editor saves notes into a sidecar. The producer replaces the cut at 16:00. The editor's next open sees the new cut, or a conflict if their client cached the old one. Nobody sent a file. On Friday the producer instead emails a link, the editor downloads, and the producer deletes the account copy. The editor still has Friday's bytes. That second path was a transfer completed through a share link. The audit question is whether you needed the recipient to keep seeing updates, or to walk away with a frozen file.

Sharing needs access control on the live object. Transfer needs a completion check on the copy. A client portal can do either. Ask which one the ticket requires before you pick the button labeled share.