Issue metadata
Sign in to add a comment
|
Zero byte *.CRDownload file left after completion of download
Reported by
tomac...@gmail.com,
Jun 17 2016
|
||||||||||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_1) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/51.0.2704.84 Safari/537.36 Example URL: http://www.thinkbroadband.com/download/ Steps to reproduce the problem: Note, I can't guarantee reproducibility. It happened the first time I tried, but not the second. This issue would be obvious to everyone if it happened on every computer, but maybe no one reported it. Out of 8 downloads, I have 2 of these files. 1. Download a file (any size) 2. Check if there is a .crdownload file left Similar to this report, but not exactly: https://bugs.chromium.org/p/chromium/issues/detail?id=616069&q=crdownload&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified What is the expected behavior? When download complete, temp file should be deleted. What went wrong? The temp file becomes zero bytes, but still exists. Don't know why that could happen. Did this work before? Yes Not sure, but it has been at least a month like this. Chrome version: 51.0.2704.84 Channel: n/a OS Version: OS X 10.11.1 Flash Version: Might be worth looking at in the code rather than trying hard to reproduce. Maybe 20 unique downloads might give some evidence. Also, see this bug, maybe related https://bugs.chromium.org/p/chromium/issues/detail?id=616069&q=crdownload&colspec=ID%20Pri%20M%20Stars%20ReleaseBlock%20Component%20Status%20Owner%20Summary%20OS%20Modified
,
Jun 17 2016
Looking. Would it be possible to get a net-internals log as described in https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details ? This would tell us what sequence of events led to the zero byte file being left around. I know it's not reliably reproducible, but sounds like you might have a fair chance of getting it to happen again :-) I've attached a small file to this message for your convenience. Click the 'download' button.
,
Jun 21 2016
Don't worry about pretty printing :-). We don't look at the raw JSON text. These logs can be opened by chrome://net-internals itself using the 'Import' option, which is how we analyze logs. Either way, there are no errors reported in the logs. This looks like the Apple Quick Look bug again. I'm going to merge this issue to the existing one. I'll file a bug with Apple and follow up with them this time.
,
Jun 21 2016
Well, if you are able, I would suggest that you run a timer maybe 1/2 or 1/4 second after delete to check and remove this file. Then let Apple follow up at their own pace.
,
Jun 22 2016
#7: That's a good suggestion. We may consider doing something like that given that we've received multiple reports about this bug. |
|||||||||||||||||||||||
►
Sign in to add a comment |
|||||||||||||||||||||||
Comment 1 by pauljensen@chromium.org
, Jun 17 2016Components: -Internals>Network UI>Browser>Downloads