Tested the issue on Chrome Stable# 61.0.3163.98 & Chrome Canary# 63.0.3239.0 on Pixel (Android 8.0.0 / OPR1 170623.027) and Pixel XL (Android 7.1.2 / N2G48E) and could not reproduce the issue. 

@xingliu -- Could you please let me know the devices where the issue is reproducible and if possible also provide a screen cast which would help us to triage further.
Thanks in Advance.

This comes from user feedback, I think the way to repro is:
1. download in chrome.
2. close chrome app, rename the file with Android download app or something else.
3. Open Chrome, the download entry is gone, because we have some logic to remove the entry.

This is expected, but make use rethink if remove the entry in the code is the correct thing to do.

Able to reproduce the issue in Android, Observed the downloaded file is getting removed from Downloads after renaming the file.

Steps Followed:
1. Launched Browser
2. Navigated to a random page, downloaded a file, closed Chrome
3. Navigated to Downloads and renamed the file
4. Observed the downloaded file is getting removed from Downloads after renaming the file.

Chrome versions tested:
61.0.3163.98, 64.0.3241.0

OS
Android 8.0.0

Android Devices
8.0.0 Pixel Build/OPR1 170623.027

This issue is observed in M58 as well.

Please navigate to below link for log's and video--
go/chrome-androidlogs/774870

Thanks!!

We are looking at adding rename capabilities in the Chrome downloads flow and UI. For now, if the user renames the file, Chrome has no way to track it and it is not shown in the UI. The feedback incorrectly states that the download is deleted. In fact it is just not shown in the Chrome UI, but is available in the file explorer.

 Issue 806198  has been merged into this issue.

I had the same problem with Android O. 
My second sep.
1. Update chrome to latest version in play store
2. Download something through Chrome.
3. Launch Files(com.android.documentsui), rename the file you downloaded just now.
4. Launch chrome > menu > Downloads to check the downloaded file, missing
5. switch to Files to check the file, File is missing.

In Chrome download menu, the missing behavior is expected.

But if the file is actually deleted, then it might be worthwhile to check again.

Dear sir:

On my android o device, the file is actually deleted,can you please help to confirm it? 

Steps:
1. Update chrome to latest version in play store
2. Download something through Chrome.
3. Launch Files(com.android.documentsui), rename the file you downloaded just now.
4. Launch chrome > menu > Downloads to check the downloaded file, missing
5. switch to Files to check the file, File is missing.

I have reproduced it on Android 8.0, 8.1 But can not repro it on 7.0

Thank you

Dear sir:

I have attach the logs logs.tar.xz, In logs you can find the delete message in alog:

01-26 14:50:17.113 19957 22665 V DownloadManager: Deleting /storage/emulated/0/Download/picture02.jpeg via provider delete

Thank you

Deleted: logs.tar.xz 620 KB

logs.tar.xz 620 KB Download

Found the deleting log is by Android's DownloadProvider. 

possibly an android bug.
When the download is added to the Android DownloadManager using addCompletedDownload, the Android DownloadManager will manage the file. If Chrome gets deleted, the file will also get deleted. So the rename behavior is probably also related to that

I can reproduce it, somehow Android's DownloadProvider.delete() is triggered, trying some other applications to see if it also happens.

The call stack of the remove triggered by Chrome: we check externally remove and tell Android to remove it.
D cr_@@@  : [DownloadManagerService.java:996] removeDownload
02-01 12:52:36.529 31938 31938 W System.err: java.lang.Exception: Stack trace
02-01 12:52:36.530 31938 31938 W System.err: 	at java.lang.Thread.dumpStack(Thread.java:1348)
02-01 12:52:36.530 31938 31938 W System.err: 	at org.chromium.chrome.browser.download.DownloadManagerService.removeDownload(DownloadManagerService.java:997)
02-01 12:52:36.530 31938 31938 W System.err: 	at org.chromium.chrome.browser.download.ui.DownloadHistoryItemWrapper$DownloadItemWrapper.removePermanently(DownloadHistoryItemWrapper.java:387)
02-01 12:52:36.530 31938 31938 W System.err: 	at org.chromium.chrome.browser.download.ui.DownloadHistoryAdapter.updateDeletedFileMap(DownloadHistoryAdapter.java:267)
02-01 12:52:36.530 31938 31938 W System.err: 	at org.chromium.chrome.browser.download.ui.DownloadHistoryAdapter.onDownloadItemUpdated(DownloadHistoryAdapter.java:390)
02-01 12:52:36.530 31938 31938 W System.err: 	at org.chromium.chrome.browser.download.DownloadManagerService.onDownloadItemUpdated(DownloadManagerService.java:1456)
02-01 12:52:36.530 31938 31938 W System.err: 	at o

The reason we have this behavior is to fix crbug/658829. Where we use an Id provided by Android to let Android to remove the download to avoid a crash.

A reasonable fix is probably use Android DownloadManager API to check if the file path in Android's database is same as the path in Chrome's database.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/88276e189cc40e61a2f60fffd2b7a49b63af6695

commit 88276e189cc40e61a2f60fffd2b7a49b63af6695
Author: Xing Liu <xingliu@chromium.org>
Date: Tue Feb 06 18:53:27 2018

Android Download: Fix an issue that Chrome removes external renamed file.

When user downloads a file in Chrome and remove the file in other
application, we check if the file is externally removed and call
Android API DownloadManager.remove(id) to avoid a crash on Android.

However, if the user rename the file, currently Chrome still deletes it
via the id provided by Android DownloadManager.

In this CL, we only let Android remove the file if it's deleted in
Chrome.


Bug:  774870 
Change-Id: I5448a155c1e05e44ec3a812e93d3035d7061ecf7
Reviewed-on: https://chromium-review.googlesource.com/899770
Reviewed-by: Min Qin <qinmin@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: Xing Liu <xingliu@chromium.org>
Cr-Commit-Position: refs/heads/master@{#534738}
[modify] https://crrev.com/88276e189cc40e61a2f60fffd2b7a49b63af6695/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerDelegate.java
[modify] https://crrev.com/88276e189cc40e61a2f60fffd2b7a49b63af6695/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
[modify] https://crrev.com/88276e189cc40e61a2f60fffd2b7a49b63af6695/chrome/android/java/src/org/chromium/chrome/browser/download/ui/BackendProvider.java
[modify] https://crrev.com/88276e189cc40e61a2f60fffd2b7a49b63af6695/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
[modify] https://crrev.com/88276e189cc40e61a2f60fffd2b7a49b63af6695/chrome/android/javatests/src/org/chromium/chrome/browser/download/ui/StubbedProvider.java

jimmyjpchen@ Thank you for reporting this issue.

Dear xingliu:

Can you tell me the chrome version that include this fix ?

Thank you

M66.

Dear xingliu:

What does M66 mean ? Major version 66 for mobile ?
Could you please help to tell me the exactly version code?

Thank you

Issue 807949 has been merged into this issue.

jimmyjpchen@, version after 66.0.3343.2 should include this fix.

@ xingliu@chromium.org:
We had raised a ctbug: https://bugs.chromium.org/p/chromium/issues/detail?id=807949
which is merged to this id.
This issue is very critical and we are getting multiple VOC raised by users for samsung model. Is it possible to include the fix of this problem in latest version. M66 would be too late. 

mili.adlakha@, yes, I can try to merge it to 65.

Add cmasso@ for merge request to M65. Please see comment 27#. Thanks.

This bug requires manual review: We are only 12 days from stable.
Please contact the milestone owner if you have questions.
Owners: cmasso@(Android), cmasso@(iOS), bhthompson@(ChromeOS), govind@(Desktop)

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

Merging this fix at this point into the release branch really depends on how safe it is overall. Can you elaborate on that xingliu@?

I think this fix will not introduce crash in Chrome. Should be safe.

crbug/658829 for details why we introduce Android deletion logic, that when user deletes a file in Chrome and open in Android Photos in Android 7.0, Photos app may crash.

The worst case scenario for this fix is, that user renames it in other app, and those apps didn't synchronize with Android download manager, and apps like Photos that uses Android download manager may crash, where Chrome shouldn't be blamed in this case.

I'd say merge this fix is reasonable, since from users' perspective, if renaming a file, the user pretty much want to keep the file, and deletion in this case looks really bad.

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/e01f61346c970c5318541d1258c9df44c461f96d

commit e01f61346c970c5318541d1258c9df44c461f96d
Author: Xing Liu <xingliu@chromium.org>
Date: Wed Feb 21 22:44:15 2018

Android Download: Fix an issue that Chrome removes external renamed file.

When user downloads a file in Chrome and remove the file in other
application, we check if the file is externally removed and call
Android API DownloadManager.remove(id) to avoid a crash on Android.

However, if the user rename the file, currently Chrome still deletes it
via the id provided by Android DownloadManager.

In this CL, we only let Android remove the file if it's deleted in
Chrome.


TBR=xingliu@chromium.org

(cherry picked from commit 88276e189cc40e61a2f60fffd2b7a49b63af6695)

Bug:  774870 
Change-Id: I5448a155c1e05e44ec3a812e93d3035d7061ecf7
Reviewed-on: https://chromium-review.googlesource.com/899770
Reviewed-by: Min Qin <qinmin@chromium.org>
Reviewed-by: David Trainor <dtrainor@chromium.org>
Commit-Queue: Xing Liu <xingliu@chromium.org>
Cr-Original-Commit-Position: refs/heads/master@{#534738}
Reviewed-on: https://chromium-review.googlesource.com/930037
Reviewed-by: Xing Liu <xingliu@chromium.org>
Cr-Commit-Position: refs/branch-heads/3325@{#544}
Cr-Branched-From: bc084a8b5afa3744a74927344e304c02ae54189f-refs/heads/master@{#530369}
[modify] https://crrev.com/e01f61346c970c5318541d1258c9df44c461f96d/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerDelegate.java
[modify] https://crrev.com/e01f61346c970c5318541d1258c9df44c461f96d/chrome/android/java/src/org/chromium/chrome/browser/download/DownloadManagerService.java
[modify] https://crrev.com/e01f61346c970c5318541d1258c9df44c461f96d/chrome/android/java/src/org/chromium/chrome/browser/download/ui/BackendProvider.java
[modify] https://crrev.com/e01f61346c970c5318541d1258c9df44c461f96d/chrome/android/java/src/org/chromium/chrome/browser/download/ui/DownloadHistoryItemWrapper.java
[modify] https://crrev.com/e01f61346c970c5318541d1258c9df44c461f96d/chrome/android/javatests/src/org/chromium/chrome/browser/download/ui/StubbedProvider.java

When we are testing it internally, it seems the issue is fixed on 65.0.3325.109. Can you please confirm the exact version? 
As we are still receiving many VOCs that the downloaded files are getting deleted.
Can the analysis be done on the logs shared by user.

Deleted: dumpState_1522752519190.zip 5.9 MB

dumpState_1522752519190.zip 5.9 MB Download

Issue 822498 has been merged into this issue.

Can I get the access for ID: 822498