Build #: PPWS29.183-29-1-9
OS: Android 9
Android's DownloadManager has a function called cleanOrphans; files that have passed through the Downloads folder and then get moved to a different folder get seen as orphaned files by DownloadManager, which deletes them when the device enters a doze mode idle maintenance window.
Even though the files have been moved out of the folder, it's still able to find them to delete them, perhaps it's storing file inode # and looking it up by them.
I set up a service using termux and inotifywait to monitor the folder that my stuff was being removed from, and it logged a series of DELETE calls to the files, which helped me track it down in logcat. Interestingly, the files were not opened and they didn't have their attributes checked, it simply started with the DELETEs.
Snippet:
```
Watcher: DELETE image0-23.jpg @ Thu Jan 30 04:28:04 EST 2020
Watcher: DELETE image-1.jpg @ Thu Jan 30 04:28:06 EST 2020
Watcher: DELETE image-2.jpg @ Thu Jan 30 04:28:09 EST 2020
Watcher: DELETE image-1.png @ Thu Jan 30 04:28:11 EST 2020
Watcher: DELETE image-3.jpg @ Thu Jan 30 04:28:13 EST 2020
Watcher: DELETE image-4.jpg @ Thu Jan 30 04:28:16 EST 2020
Watcher: DELETE image-5.jpg @ Thu Jan 30 04:28:20 EST 2020
```
Logcat of when it happened:
```
01-30 04:27:37.837 1043 9368 D vold : idle maintenance started
01-30 04:27:37.880 1043 9368 D vold : Starting trim of /data
01-30 04:27:38.394 1043 9368 I vold : Trimmed 0 bytes on /data in 513ms
01-30 04:27:38.394 1043 9368 D vold : Starting trim of none
01-30 04:27:38.394 1043 9368 W vold : Failed to open none: No such file or directory
01-30 04:27:38.394 1043 9368 D vold : Starting trim of /persist
01-30 04:27:38.660 1043 9368 I vold : Trimmed 19324928 bytes on /persist in 265ms
01-30 04:27:38.660 1043 9368 D vold : Starting trim of /mnt/vendor/persist
01-30 04:27:38.660 1043 9368 W vold : Failed to open /mnt/vendor/persist: Permission denied
01-30 04:27:38.662 1043 9368 D vold : idle maintenance completed
01-30 04:27:38.794 2151 2182 I chatty : uid=1000(system) Binder:2151_1 expire 12 lines
01-30 04:27:40.302 1366 1550 E storaged: getDiskStats failed with result NOT_SUPPORTED and size 0
01-30 04:27:41.095 17722 17477 D DownloadManager: Removed 0 stale downloads
01-30 04:27:41.135 2151 3741 I chatty : uid=1000(system) Binder:2151_10 expire 10 lines
01-30 04:27:41.189 2151 2505 I chatty : uid=1000(system) NetworkWatchlis expire 2 lines
01-30 04:27:41.219 2151 2213 I chatty : uid=1000(system) ActivityManager expire 11 lines
01-30 04:27:42.045 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/animation0-4.gif, deleting 4117
01-30 04:27:42.997 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/139748760132.jpg, deleting 4118
01-30 04:27:43.119 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/animation0-5.gif, deleting 4119
01-30 04:27:43.345 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/139105418232.jpg, deleting 4120
01-30 04:27:43.480 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/136605285441.jpg, deleting 4121
01-30 04:27:43.578 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/8ed6f01f-9ce7-4972-a058-c5bae4f92aed.jpg, deleting 4122
01-30 04:27:43.666 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/1503164927.png, deleting 4123
01-30 04:27:43.872 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/image0-23.jpg, deleting 4124
01-30 04:27:43.964 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/image-1.jpg, deleting 4125
01-30 04:27:44.105 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/image-2.jpg, deleting 4126
01-30 04:27:44.182 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/image-1.png, deleting 4127
01-30 04:27:44.278 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/image-3.jpg, deleting 4128
01-30 04:27:44.356 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/image-4.jpg, deleting 4129
01-30 04:27:44.450 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/image-5.jpg, deleting 4130
01-30 04:27:44.613 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/8rQ9X50.jpg, deleting 4131
01-30 04:27:44.742 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/ol5me5qagea99.png, deleting 4132
01-30 04:27:44.845 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/1uidureiv1a87.jpg, deleting 4133
01-30 04:27:44.933 17722 17477 D DownloadManager: Missing /storage/emulated/0/Download/nrqv5hE.jpg, deleting 4134
01-30 04:27:45.060 17722 17477 D DownloadManager: Found 879 files in database
01-30 04:27:45.060 17722 17477 D DownloadManager: Found 5 files on disk
01-30 04:27:59.572 2151 3738 I chatty : uid=1000(system) Binder:2151_E expire 15 lines
01-30 04:27:59.572 2151 2620 I chatty : uid=1000(system) Binder:2151_3 expire 10 lines
01-30 04:27:59.573 2151 4367 I chatty : uid=1000(system) Binder:2151_1B expire 6 lines
01-30 04:27:59.573 2151 3379 I chatty : uid=1000(system) Binder:2151_A expire 10 lines
01-30 04:27:59.576 2151 4358 I chatty : uid=1000(system) Binder:2151_13 expire 12 lines
```
In my case, the images I was downloading were things like brand assets, family pictures from Facebook, memes, and so on. I then sorted them into folders via the Google Photos app.
There's many, many cases of this happening to people:
https://support.google.com/photos/thread/200457?hl=en "Pictures got deleted on their own", 909 replies, varied issues here but many people describing the same situation
https://support.google.com/photos/thread/106201?hl=en "Photos disappeared after moving to another device folder", 55 replies, same situation described
https://support.google.com/photos/thread/560768?hl=en This user has Google photos backup turned on so they don't actually lose the images, but they get repeatedly deleted from the device.
Note this sentence: "..., and it ends up downloading them to a "Downloads" album/folder in the Google Photos app, and I have to RE-organize into the albums/folders they were in" indicating that they pass through the Downloads folder first, thus through DownloadManager.
I found one mention of cleanOrphans here: https://issuetracker.google.com/issues/78078399
A patch was submitted, but never merged.
https://android-review.googlesource.com/c/platform/packages/providers/DownloadProvider/+/674009
Eventually, it was closed automatically.
I would appreciate more attention to this issue. I've lost a lot of great memes...as well as brand assets and such that I painstakingly sorted into their own folders, only for them to be summarily removed. But beyond the images/videos being lost, it could be more important things, such as PDFs with receipts, etc.
Steps to reproduce:
- Download some images or videos
- Move them to a different folder (I used the Google Photos app to do the actual move, but I don't think that matters)
- Wait overnight for the system to do its doze mode maintenance and for DownloadManager's cleanOrphans to run
- Your files are now gone
Issue summary
Comments
pa...@gmail.com <pa...@gmail.com> #2
za...@gmail.com <za...@gmail.com> #3
It doesn't seem to actually be
You can force it to run immediately with the following ADB command:
adb shell cmd jobscheduler run -f com.android.providers.downloads -100
Testing on a Galaxy Note9 running Android Pie and an OPPO Reno2, also running Android Pie, I can't reproduce this by forcing DownloadIdleService to run. While it does create the log entries you're seeing, it doesn't actually delete the files that have been moved. I've tried moving them using Google Photos, OPPO's built-in Photos app, Samsung's My Files, app, and MiXPlorer. I've tried downloading images from both Chrome and Discord.
There's also
// File appears to live on internal storage, or a
// currently mounted device, so remove it from database.
// This logic preserves files on external storage while
// media is removed.
This (and the corresponding code) tells me it only deletes the database entry, and doesn't actually touch the filesystem.
Unfortunately, I think it's something else in the maintenance cycle that isn't directly related to DownloadManager.
te...@google.com <te...@google.com>
te...@google.com <te...@google.com> #4
Android bug report (to be captured after reproducing the issue)
For steps to capture a bug report, please refer: https://developer.android.com/studio/debug/bug-report#bugreportdevice
Alternate method
Navigate to “Developer options”, ensure “USB debugging” is enabled, then enable “Bug report shortcut”. Capture bug report by holding the power button and selecting the “Take bug report” option.
Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.
ap...@sudomemo.net <ap...@sudomemo.net> #5
Hey, thanks for the instructions. I have some questions about the actual timing of the bug report, however. I think I can have Termux do the same thing as before but also trigger a bug report when it detects that files have started being deleted (I believe there is an intent I can signal via am
to do this, but can't recall off the top of my head) Should this be done before the deletion starts, during, or after? Doing it before might be a bit of a challenge as I can't access system-wide logcat from within Termux, though I suppose I could hook it up to my laptop and watch logcat to trigger it.
Cheers,
Austin.
te...@google.com <te...@google.com> #6
Note: Please upload the files to google drive and share the folder to android-bugreport@google.com, then share the link here.
td...@gmail.com <td...@gmail.com> #7
te...@google.com <te...@google.com> #8
ap...@sudomemo.net <ap...@sudomemo.net> #9
I should have the bugreport by tomorrow or the day after - it's taken a bit to come up with a way to take the report, but I now have something that will play loud music right when it happens, waking me up so I can take the bug report.
ap...@gmail.com <ap...@gmail.com> #10
It's been shared with that email address.
vc...@gmail.com <vc...@gmail.com> #11
te...@google.com <te...@google.com> #12
as...@gmail.com <as...@gmail.com> #13
sa...@outlook.com <sa...@outlook.com> #14
wi...@gmail.com <wi...@gmail.com> #15
li...@gmail.com <li...@gmail.com> #16
ga...@gmail.com <ga...@gmail.com> #17
kh...@gmail.com <kh...@gmail.com> #18
ma...@gmail.com <ma...@gmail.com> #19
sa...@outlook.com <sa...@outlook.com> #20
ta...@gmail.com <ta...@gmail.com> #21
ta...@gmail.com <ta...@gmail.com> #22
t....@e3n.de <t....@e3n.de> #23
sa...@outlook.com <sa...@outlook.com> #24
ra...@gmail.com <ra...@gmail.com> #25
c9...@gmail.com <c9...@gmail.com> #26
rd...@gmail.com <rd...@gmail.com> #27
lo...@gmail.com <lo...@gmail.com> #28
sa...@gmail.com <sa...@gmail.com> #29
sa...@google.com <sa...@google.com>
br...@gmail.com <br...@gmail.com> #30
xa...@gmail.com <xa...@gmail.com> #31
he...@gmail.com <he...@gmail.com> #32
Is there no fix?? No workaround for now? I need things separated into albums.
da...@gmail.com <da...@gmail.com> #33
sa...@gmail.com <sa...@gmail.com> #34
Nice to see Google has not moved in almost a whole year. That's great service.
ww...@gmail.com <ww...@gmail.com> #35
So...@hotmail.com <So...@hotmail.com> #36
ju...@gmail.com <ju...@gmail.com> #38
ho...@gmail.com <ho...@gmail.com> #39
ah...@gmail.com <ah...@gmail.com> #40
coz this is realy frustrating !
li...@gmail.com <li...@gmail.com> #41
su...@gmail.com <su...@gmail.com> #42
https://drive.google.com/drive/folders/1RrxjrnRdh0k3Kz_GBBYHUbUT8zW1-uTp