Limit scanning from FUSE rename.
Initiating a media scan from a FUSE rename context can lead to lock-ups,
because the kernel may hold a lock on the (source) inode. As part of
scanning media files, we may pass the path to MediaServer or DrmServer
for metadata retrieval, and those processes in turn may try to close a
file descriptor to the underlying file; this close may require the lock,
and hang indefinitely.
The reason we scanned was two-fold:
1) To fix the mime/media-type of renamed files in case they were moved
to/from a hidden folder
2) To deal with moving to/from a .nomedia file
This change fixes 1) by explicitly looking for hidden dirs, and fixing
up the mime/media-type as part of the rename.
And we now do the scan only for case 2). While in theory this leaves a
possible scenario where somebody renames from a .nomedia to a valid
media file, that seems extremely unlikely, and at this point this seems
the safest fix.
Bug: 156867379
Test: atest CtsScopedStorageHostTest
Change-Id: I5733cc7f9cae99e9eebbfa680230adacc307d739
4 files changed