Could you attach a net-internals log per these instructions? Thanks!
https://dev.chromium.org/for-testers/providing-network-details

@asanka@chromium.org
uuh this is not a duplicate of 64062 ! The issue of this ticket was that people didn't like the fact that chrome adds the ".crdownload" extension. Here the problem is that since an update of this summer, chrome will automatically restart the download of a file if he cannot access to this file at the end of the download, for example if you opened it with vlc. This is extremely annoying because if the file is a video, the video just stops. We now have to wait the file is completely downloaded before watching the video.

#4: Changing the extension alone doesn't address the issue described in 64062. Opening a file while it's being downloaded currently interferes with the download operation and hence causes the download to fail. The resolution for both this and issue 64062 is to support streaming, both by having a usable name and also by reworking the download logic to be permissive of other application keeping the file open during the download operation. See https://bugs.chromium.org/p/chromium/issues/detail?id=658393#c1

this is annoying. i prefer chrome over firefox but if its the only way... can you please just allow the non-idiots to disable auto download resume in the chrome://flags menu please, thank you.

 Issue 688639  has been merged into this issue.

As stated before, its not a duplicate of 64062. The problem is that a "finished" download gets rejected, because renaming/deleting the .crdownload file is impossible because it is read_opened by another process. What happens then is that the download restarts into the .crdownload file. I guess what should happen depends on the os. Some systems should be able to rename the file while other processes have a read handle. If thats not possible, i guess the best solution would be to just copy the complete download to the correct filename. Then, when  the .crdownload file is closed by all other processes it can be deleted. Or, alternatively, just state that the rename is impossible, since its opened by other processes and consider the download as finished.

Yes Nicht has it right! Please give us an option to Change Download Resumption. Worst thing to happen to Chrome.

Yes, this is a serious usability flaw, and has virtually nothing to do with issue 64062 (whoever merged them needs to work on their reading comprehension before knee-jerking a factually incorrect response). 

This behavior is relatively new, and could be resolved in a number of ways without in any way addressing 64062:

1. If the entire file was downloaded, do not restart simply because of an inability to rename the file. Leave the completed (but not renamed) file in situ, and report an error. 

2. Save a duplicate.

3. And, yes, have an option to not have crdownload would resolve this. But that's actually throwing baby out with the bathwater, which is why I find the merge so inappropriate. 

I made a new issue because the merge is indefensible, and yet still the fact. 

I'm also finding this very irritating! I've used Chrome for years, but now its auto-resume function interfers with me trying to open files that its downloading (like using VLC to stream a file Chrome is donwloading)

It would be nice if they just allowed us to change that option in Chrome://flags

I don't think this should be closed as duplicate. This issue is distinct from that of 64062, and can be solved simply be re-exposing the flag "Download Resumption" that used to exist in Chrome://flags.

I've given up on the Chrome team.  There aren't even buried options like in the past for the user to fix.  Mozilla Firefox and sadly Internet Explorer don't have this problem so I use those two for downloads.  Pretty ridiculous.

This bug came up in June 2016.  The "duplicate" that this is being claimed to be is from 2012.  Everything was working fine for us before June 2016.

Come on Chrome team.  Actually read this bug again; it is still an issue.

We need the "Disable auto-resume" function back in chrome://flags

We cannot view partially downloaded videos without Chrome trying to make the final save from .crdownlaod to "regular", failing, and deleting the file, stopping playback.

This is not a feature request, this is a bug with Chrome deleting downloads and restarting them if we have them opened whilst downloading.

Issue:

When Chrome finishes a download, but is unable to rename the file to remove the .crdownload suffix, then chrome will delete all the data in the completed file!

(Note: Chrome will automatically start the download over, and if the file continues to not be able to rename, then a download loop will occur and Chrome will download the file again and again and again for eternity).

How hasn't this been fixed yet? this CLEARLY A HUGE problem with Chrome.

The only thing I can think is that it is intentional. Google doesn't want people streaming downloads for some reason.

yes, i too have been facing the same issue, this might not be much of a problem for those who have unlimited data, but in several countries data is precious especially since video files consume so much of data, restart of downloads when i am running unfinished video in my videoplayer consumes double as much data which is loss of precious money for me. Kindly, rectify the issue quickly.

This issue for which has been driving me nuts when I forget about it and us Chrome to watch something streaming on VLC and in the middle of my show it stops. Just to let Google know before summer 2016 I was a 95% Chrome user but now it more like 95% Firefox and its only because to this issue. Too bad you don't seem to believe it needs a fix.

SO now, I see that others are having the same issue. The problem is that it is difficult to describe for a google search, so I had stopped trying. Now I find out that it's because chrome devs decided to remove a flag. Wow, just put the damn flag back so that we can change it again, it's not that fucking hard. Jesus, ffs.

I have opened a new Issue: https://bugs.chromium.org/p/chromium/issues/detail?id=847701

Let's see they still refuse to understand it.