Skip to content

fix: remove a shared source file after the share, at sign-out and with Remove my data - #219

Merged
cevheri merged 3 commits into
mainfrom
fix/202-share-temp-file-cleanup
Oct 24, 2026
Merged

cevheri merged 3 commits into
mainfrom
fix/202-share-temp-file-cleanup

Conversation

@cevheri

@cevheri cevheri commented Oct 24, 2026 •

Copy link
Copy Markdown
Member

A source longer than 100,000 characters is now written through TemporaryShareFiles to <temp>/share_files/ and deleted once the share sheet answers, whether the share succeeded or failed.
If a sign-out already removed the file while the sheet was open, the delete succeeds quietly.
Every sign-out (the session wipe in AuthSessionRepository.clear) and Remove my data (a new share_files entry in UserDataRegistry) remove that folder and share_plus's Android copy in <cache>/share_plus/.
A sign-in also removes them before it stores the new session, which covers a share the app was killed in before a session that ended without the wipe.
A removal the phone refuses is never ignored: a share shows a snackbar, a sign-out shows the "data stayed behind" notice, Remove my data shows its usual failure with Retry, and a sign-in is refused with auth.share_files_not_removed.
The registry guard lists the new path_provider user.
test/app/di/source_share_cleanup_test.dart reproduces the bug through AppScope and failed on main.
TestEnv now answers getTemporaryDirectory with a temporary folder for each test, because every sign-out in a widget test now clears the share files.
Sharing a short source as text is unchanged.
Files that earlier builds left in <temp>/<uuid>/ stay where they are, since no Play build has shipped.

Closes #202

@cevheri
cevheri force-pushed the fix/202-share-temp-file-cleanup branch from bc5af5b to 5fa59ce Compare October 24, 2026 17:05
…h Remove my data

A source longer than 100,000 characters was shared as a file that share_plus left in the temporary directory, next to its Android copy in share_plus/, so the next account on the phone could read it.
The app now writes that file through TemporaryShareFiles and deletes it once the share sheet answers.
Every sign-out (the session wipe) and Remove my data (a new UserDataRegistry entry) remove its folder and the share_plus copy, and a refused removal is shown instead of ignored.

Closes #202
…already removed

A sign-out while the share sheet was open removed the share's folder, and the removal after the share then reported the file as left on the phone.
A share the app was killed in, followed by a session that ended without the wipe, left its file to the next account; the sign-in now removes the share files before it stores the session, and a refused removal refuses the sign-in.
@cevheri
cevheri force-pushed the fix/202-share-temp-file-cleanup branch from 5fa59ce to f8e8412 Compare October 24, 2026 17:38
@cevheri
cevheri merged commit 7cd16a6 into main Oct 24, 2026
6 checks passed
@cevheri
cevheri deleted the fix/202-share-temp-file-cleanup branch October 24, 2026 18:19
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

A shared long object source stays in a temporary file after sign-out and Remove my data

1 participant