As noted in Issue 825228 Comment #8, we found that when extension reads a file in Drive not yet cached locally, it can schedule downloads duplicated without noticing that there's already ongoing download, and actually conducts download multiple times.
Zip Archiver has been fixed not to launch loading of ZIP file duplicatedly, thus avoiding the issue, but we still potentially have the issue with other extensions that reads Drive files.
As noted in Issue 797854 Comment #8, we found that when extension reads a file in Drive not yet cached locally, it can schedule downloads duplicated without noticing that there's already ongoing download, and actually conducts download multiple times.
Zip Archiver has been fixed not to launch loading of ZIP file duplicatedly, thus avoiding the issue, but we still potentially have the issue with other extensions that reads Drive files.
Relevant comment in Issue 797854:
Comment 5 by hashimoto@chromium.org, Jan 5
> I think it's better to store the download info somewhere on memory, instead of in FileCacheEntry which is persisted on the disk.
>
> The current implementation does not change the cache state until download completes.
> The downloaded file is stored in the temporary directory so the file may be erased If the machine reboots while download is in progress.
> If we change a FileCacheEntry's state for an ongoing download, the persisted FileCacheEntry's flag can contradict with the actual state of the downloaded file after a reboot.
Comment 1 by yamaguchi@chromium.org
, Mar 27 2018