mkarkada@ - If you close the window and then reopen the app -> Recent, does the image then appear? I'm wondering if this is due to a known issue where the folder doesn't refresh in real time. We are making some updates in M63 to handle this ( crbug.com/758622 ).

Hi weifangsun, Even on closing the window and reopening Files app, I didn't see those files of Downloads folder under Recent root.

nya@ - Could you please take a look this bug?

I have several questions:

- From which directory did you copy a file to Downloads folder?
- What is the last modified timestamp of the file you copied?

Hi nya, I tried copying existing file of USB/GDrive to Downloads folder. This file didn't appear in Recent root. 
The file that was copied had old date timestamp. 

Thanks for feedback. I believe it's WAI because last modified time of the copied files is preserved, and Recent root shows most recently modified files.

But the same old file (i.e. of old date timestamp) copied from USB/Downloads to Gdrive causes the file to appear in Recent folder. As I have observed, when file is copied to Gdrive, its last modified time gets updated to current timestamp. 

So, similarly shouldn't the timestamp of file copied to Downloads folder change to current datetime?

Sorry for late reply. Yes, indeed this is inconsistent.

To summarize, the problem is that:
- When a file is copied from Downloads to Drive, last modified is NOT preserved.
  - This means that when an old file is copied from Downloads to Drive, it appears in Recent.
- When a file is copied from Drive to Downloads, last modified is preserved.
  - This means that when an old file is copied from Drive to Downloads, it does NOT appear in Recent.

I'll investigate why the timestamp handling is inconsistent by destination.

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

commit 23c7a54d77b7efe746f355732df9d0fab64a069c
Author: Shuhei Takahashi <nya@chromium.org>
Date: Tue Nov 14 04:25:35 2017

Set correct file timestamp on streaming file copy.

Today, on streaming file copy, the destination file is closed on the
destruction of SnapshotCopyOrMoveImpl which happens after setting the
timestamp of the file with TouchFile(). This works in an undesired way
with some file systems which update timestamps on file close (including
Drive): the timestamp set with TouchFile() is reverted immediately.

This change updates SnapshotCopyOrMoveImpl to destruct StreamCopyHelper
immediately after it is used so that the destination file is closed
before TouchFile() is called.

Bug:  770012 
Test: Copying a file from Downloads to Drive retains its timestamp.
Change-Id: I4a430a347e3d8d524c8b8d00bfe9479e22f7d5c9
Reviewed-on: https://chromium-review.googlesource.com/765748
Reviewed-by: Taiju Tsuiki <tzik@chromium.org>
Reviewed-by: Ryo Hashimoto <hashimoto@chromium.org>
Commit-Queue: Shuhei Takahashi <nya@chromium.org>
Cr-Commit-Position: refs/heads/master@{#516191}
[modify] https://crrev.com/23c7a54d77b7efe746f355732df9d0fab64a069c/storage/browser/fileapi/copy_or_move_operation_delegate.cc

Copying a file from Downloads to Drive retains its timestamp.