Avoid unlink/rename when replacing regular files on Android - #245
Merged
Merged
Conversation
Android's September 2026 security patches [0] changed the MediaProvider behavior so that it revokes app permissions on unlink and rename within its FUSE filesystem, which is used for both internal storage (/sdcard) and external storage (SD cards and USB drives). For rename, permissions for both paths are revoked as it does: revoke destination -> rename -> revoke source. Unfortunately, this means it is now impossible to keep app permissions to files in a shared folder while performing atomic file replacement. This commit works around the problem by performing in-place overwrites when replacing regular files. This essentially forces the use of the fallback path of osutil.RenameOrCopy() when the destination is on a FUSE filesystem on Android. The statfs magic check is sufficient since the only FUSE filesystem openable by path on Android is MediaProvider's. [0] https://android.googlesource.com/platform/packages/providers/MediaProvider/+/91dddac65b6ef48ae54302fa852029c2fcf010aa Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
chenxiaolong
force-pushed
the
android-sep-2026
branch
from
September 16, 2026 03:31
dd27255 to
ff60304
Compare
chenxiaolong
added a commit
that referenced
this pull request
Sep 16, 2026
Signed-off-by: Andrew Gunnerson <accounts+github@chiller3.com>
Owner
Author
|
I reported this to upstream Syncthing to see if they have any better ideas for optionally performing in-place file replacements: syncthing/syncthing#10887 |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Android's September 2026 security patches [0] changed the
MediaProviderbehavior so that it revokes app permissions on unlink and rename within its FUSE filesystem, which is used for both internal storage (/sdcard) and external storage (SD cards and USB drives). For rename, permissions for both paths are revoked as it does: revoke destination -> rename -> revoke source.Unfortunately, this means it is now impossible to keep app permissions to files in a shared folder while performing atomic file replacement.
This commit works around the problem by performing in-place overwrites when replacing regular files. This essentially forces the use of the fallback path of
osutil.RenameOrCopy()when the destination is on a FUSE filesystem on Android. Thestatfsmagic check is sufficient since the only FUSE filesystem openable by path on Android isMediaProvider's.[0] https://android.googlesource.com/platform/packages/providers/MediaProvider/+/91dddac65b6ef48ae54302fa852029c2fcf010aa