Or maybe, chrome checks if the target filename already exists at start of download, but since it downloads to a temp file first, this is racy. (And the case-sensitivity of the file system doesn't matter.) I didn't test in detail. Probably easy to see for people familiar with that code what's going on.

Moving this nonessential bug to the next milestone.

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

The logic we have should take in-progress downloads into account as well as files that are on the disk already. I'll see what happened here.

This issue is Pri-1 but has already been moved once. Lowering the priority and moving to the next milestone.

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

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

commit 3f4e2aada67ac99063cc7bddf88dddf6ed93e9c0
Author: asanka <asanka@chromium.org>
Date: Mon Jul 11 19:54:13 2016

[Downloads] Path collision check should be case insensitive.

If there are two on-going downloads with suggested paths that only
differ by case, they should be considered in conflict. Thus the download
that started later should end up with a uniquified path. Otherwise the
files may overwrite each other during the final rename.

R=svaldez@chromium.org
BUG= 619516 

Review-Url: https://codereview.chromium.org/2136673002
Cr-Commit-Position: refs/heads/master@{#404711}

[modify] https://crrev.com/3f4e2aada67ac99063cc7bddf88dddf6ed93e9c0/chrome/browser/download/download_path_reservation_tracker.cc
[modify] https://crrev.com/3f4e2aada67ac99063cc7bddf88dddf6ed93e9c0/chrome/browser/download/download_path_reservation_tracker_unittest.cc

Thanks! Do you think we should merge this?

I wasn't going to since the behavior hasn't changed for quite some time. But I think a merge request is reasonable given that this bug could cause data loss.

I'll wait for a Canary cycle and request a merge.

Requesting merge due to possibility of data loss resulting from unexpectedly overwriting downloaded files. The change has baked in Canary without any adverse effects.

Your change meets the bar and is auto-approved for M53 (branch: 2785)

Re-opening for merge.

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

commit 455b0f4daaac3f4cdeead3145446be08935dc030
Author: Asanka Herath <asanka@chromium.org>
Date: Wed Jul 13 16:22:43 2016

[Merge M53] [Downloads] Path collision check should be case insensitive.

If there are two on-going downloads with suggested paths that only
differ by case, they should be considered in conflict. Thus the download
that started later should end up with a uniquified path. Otherwise the
files may overwrite each other during the final rename.

R=svaldez@chromium.org
BUG= 619516 

Review-Url: https://codereview.chromium.org/2136673002
Cr-Commit-Position: refs/heads/master@{#404711}
(cherry picked from commit 3f4e2aada67ac99063cc7bddf88dddf6ed93e9c0)

Review URL: https://codereview.chromium.org/2148873002 .

Cr-Commit-Position: refs/branch-heads/2785@{#104}
Cr-Branched-From: 68623971be0cfc492a2cb0427d7f478e7b214c24-refs/heads/master@{#403382}

[modify] https://crrev.com/455b0f4daaac3f4cdeead3145446be08935dc030/chrome/browser/download/download_path_reservation_tracker.cc
[modify] https://crrev.com/455b0f4daaac3f4cdeead3145446be08935dc030/chrome/browser/download/download_path_reservation_tracker_unittest.cc

Verified the issue on Mac 10.11.5 using 53.0.2785.21 and its working fine.Please find the screen cast for the same.Hence added the respective TE-Verified labels.

Deleted: 619516_JUly_19.mp4 1.1 MB

	619516_JUly_19.mp4 1.1 MB View Download

Its working fine on Win 7 using 53.0.2785.21 as well.