Freelance client file handover: check who controls each file
A working delivery link does not establish a retained copy. Check file-level control separately from the hosting deadline, without imposing indefinite storage.
You can change a Google Drive folder's owner and still own the files inside it. Google's guidance says so. [1]
In freelance client file handover, shared-link access to sender-hosted files does not establish recipient custody. Look for a recipient-controlled copy or a completed, supported file ownership transfer. Custody here means recipient-controlled retention, not copyright or legally sufficient delivery; usable formats and dependencies still need checking. Where independent retention is intended, check each required file's destination and control state. If those are unknown, record custody unconfirmed.
A delivery route and a retained package are different states.
Access can work while a Drive transfer is pending
Sharing a Drive file does not transfer ownership. Google requires prior sharing before a transfer; for a personal-account ownership request, the sender remains owner until the recipient accepts. The pending recipient is upgraded to Editor if necessary. [1]
A client opening or editing the file is therefore compatible with the freelancer still owning it. An access check has answered “Can they use it now?”, not “Has control changed?”
Once a supported personal-account transfer is accepted, the former owner becomes Editor. The new owner can remove them, and the file counts towards the new owner's storage. [1] Those are stronger indications of changed file control than a working link. They still do not establish package completeness or usability.
Google Drive ownership transfers also depend on account type: work/school transfers stay within the organisation and do not require acceptance. A personal account cannot transfer a file to a work/school account. [1] A recipient-controlled copy is an alternative where a transfer is unsupported.
Even a supported transfer needs the right object. The folder in the delivery message may not be the file the client needs to retain.
A changed folder owner and a dead link tell different stories
Does transferring the folder also transfer its files?
No. Google says making someone else the owner of a folder leaves ownership of its contained files unchanged. [1]
Consider two hypothetical required files, approved-brochure.pdf and brochure-source.indd. Changing the enclosing folder's owner does not establish changed ownership for either file. This example was not tested. Nor does sender ownership prove the client lacks access or a separate copy. A folder-level label cannot settle that file-level retention question.
What can remain accessible after a shared link expires?
With expired file links, a closed download route can coexist with other access. Dropbox says expiry disables the shared link, but existing directly granted permissions are unaffected by link settings. Its expiry controls apply on eligible plans. [2]
These exceptions run in opposite directions. A changed folder owner can look like a completed handover while file ownership stays put. A disabled link can look like ended access while a directly granted permission survives. Neither settles whether the client independently retained the required package.
The comparison below draws on provider guidance checked during research on 10 October 2026. No transfer or client download was observed here.
| Documented operation | What it establishes | What it leaves unknown |
|---|---|---|
| Share a Drive file | Recipient access, a prerequisite to transfer. [1] | Changed ownership or a recipient-controlled copy. |
| Request personal-account ownership transfer | Pending recipient has Editor access; sender remains owner. [1] | Completed transfer. |
| Change a Drive folder's owner | Folder owner changes; contained-file ownership does not. [1] | Control of each required file. |
| Complete a supported personal-account file transfer | New owner can remove former owner; storage counts towards new owner. [1] | Package completeness, usability, permanent backup or removal of sender permissions. |
| Expire a Dropbox shared link on an eligible plan | Link disabled; direct grants unaffected. [2] | File deletion or whether the recipient saved anything. |
WeTransfer supplies a separate expiry/recovery distinction. The sender sets availability; after expiry, recovery requires enabling it when creating the transfer and an eligible Ultimate, Teams or Enterprise plan. [3] This is conditional recovery, not Dropbox's surviving direct access. It does not promise recovery for a particular delivery.
The action's scope must match the handover claim: a folder is a container, a link is a route. Extending a window changes the opportunity to retrieve files, not the evidence that retrieval happened. The remaining question is what outcome you agreed to supply.
A download window may be all you promised
Lets Send's practitioner argument distinguishes temporary delivery from ongoing collaboration and rejects treating a transfer link as an unpaid archive. It also recognises that a copy downloaded before expiry can be kept. [5] That is a boundary argument, not measured evidence of fewer disputes.
A freelancer may have promised a clear download window, not permanent hosting or responsibility for the client's saving behaviour. A fulfilled delivery obligation can coexist with unconfirmed retention. Custody unconfirmed is not a finding of breach or failed acceptance, and it does not impose indefinite hosting.
A post on r/freelance, published on 9 October 2026, reports a 30-day download window and later file removal; those events and the provider were not independently verified. [4] This article cannot settle that agreement, recommend a minimum retention period or authorise deletion.
If the client already holds the required usable copy, a broken sender link does not establish loss. If the agreed outcome was temporary viewing or downloading, retained-copy confirmation may not be relevant at all.
I would name the intended outcome before choosing the method. These are practical options inferred from the distinctions above:
- Temporary access fits a bounded viewing/download opportunity; it cannot establish a recipient archive.
- A recipient-controlled copy fits independent retention, not necessarily live collaboration. Required formats and dependencies still need confirmation.
- A supported completed file transfer fits cloud-file control where account rules allow; it does not automatically remove sender permissions or provide permanent backup.
- Ongoing hosted collaboration fits continuing shared access; independent retention after hosting ends remains a separate question. Agree the hosting and support boundary.
Acceptance of the work, discussed in completion evidence, and retention of its files answer different questions. A custody record should say which outcome it describes.
Keep the custody record separate from the hosting deadline
Google's folder/file distinction is why I would record the required files rather than just the shared container. [1] For freelance file retention, keep the recipient's retained destination separate from the sender's hosting expectation in the client handover checklist. This four-field record is my proposal, not a process tested or endorsed by the cited providers.
Hypothetical, untested record
- Required files/version:
approved-brochure.pdfandbrochure-source.indd; confirm the agreed version and dependencies. - Retained destination/account: unconfirmed.
- File-level copy/transfer confirmation: none recorded; custody unconfirmed.
- Hosting/access/support expectation: record the agreed window and support boundary separately.
An acknowledgement without named files or destination leaves that gap open. A client's reported save should be recorded as their report, not as independently inspected retention. If there is no relevant confirmation, keep the unknown visible.
Keep delivery/access expectations retrievable with client context records. A later public-record maintenance request belongs to a different question: routing updates to the source owner, not custody of delivered files.
A hosting deadline describes a commitment. “Recipient-held files confirmed” describes evidence about named files; “custody unconfirmed” names its absence. Neither status authorises deletion.
Share this file-control comparison with a designer closing a client handover, so the hosting deadline is not mistaken for a retained copy.
References
[1] Google Drive Help, "Make someone else the owner of your file." https://support.google.com/drive/answer/2494892?hl=en . Documents prior sharing, pending personal-account requests, the folder/file ownership distinction and account-type limits. Guidance checked during research on 10 October 2026; publication/update date not displayed.
[2] Dropbox Help, "How to set or change shared link permissions," updated 20 February 2026. https://help.dropbox.com/share/set-link-permissions . Documents link expiry, eligible-plan limits and the exception for existing directly granted permissions. Guidance checked during research on 10 October 2026.
[3] WeTransfer Help, "How long are transfers available to download?" Updated 30 September 2026. https://wetransfer.com/help-center/how-to/transfer-availability . Documents sender-set availability and recovery conditions after expiry. Guidance checked during research on 10 October 2026.
[4] Reddit, r/freelance, reported temporary file handover, published 9 October 2026. https://www.reddit.com/r/freelance/comments/1x1eaf6/exclient_and_her_husband_are_harassing_my_family/ . Public account checked during research on 10 October 2026. Underlying delivery, removal and recipient behaviour are uncorroborated; provider unspecified.
[5] Lets Send, "Why expiring download links matter for client work." https://letssend.com/blog/why-expiring-download-links-matter . Practitioner/vendor argument for finite delivery windows, acknowledging retained downloaded copies. Checked during research on 10 October 2026; publication date not independently established. Not outcome research.