New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 61106 link

Starred by 30 users

Issue metadata

Status: Fixed
Owner: ----
Closed: Jan 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Blocking:
issue 68198

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment

Download name changed to "unconfirmedxxx.crdownload"

Reported by clemw@chromium.org, Oct 28 2010

Issue description

What steps will reproduce the problem?
1. Fresh install of Chrome 7.0.517.41 on Windows XP SP3
2. If default download folder doesn't exist:
3. Click on a link to download a file

What is the expected output?

Download file's name is not changed.

What do you see instead?

Download file's name is changed to "unconfirmedxxx.crdownload"

Right-clicking on the file's link and selecting "Save Link As..." prompts to save with the file's proper name and extension


Resolution steps:

See if download location folder actually exists. If not, change it to a folder that does exist, and the issue goes away.

I could not repro, but a number of users are experiencing this, and it seems to have started with 7.0.517.41. Here's the original help forum thread:

http://www.google.com/support/forum/p/Chrome/thread?fid=313479335b255dbe0004937d3fa89a9e&hl=en


 

Comment 1 by Deleted ...@, Nov 18 2010

cool 

Comment 2 by bjorns...@gmail.com, Nov 18 2010

Issue still happens on 7.0.517.44
Blockedon: 63493
Status: Assigned
Planning to fix as part of refactor mentioned in 63493

Comment 5 by Deleted ...@, Nov 21 2010

best
Status: Available
Status: Assigned
Cannot reproduce in 8.0.552.224 (Release) on Windows 7.

I've tried using non-existent download folders (they get created anyway), setting the "Always Ask" flag, and right-clicking.  I downloaded .exe files.

The correct name is displayed.

Does this still happen to others?

Comment 8 by bjorns...@gmail.com, Dec 23 2010

Appears to be fixed in 8.0.552.224 on WinXP SP3.
We believe this bug is *much* rarer in Chrome 8 due to changes in r61492, in DownloadManager::CheckIfSuggestedPathExists().

It could still happen if CreateDirectory() fails, such as by setting the default directory to be on a removable drive and then removing it.



Status: Available
 Issue 25750  has been merged into this issue.
Blockedon: -63493

Comment 13 by Deleted ...@, Feb 4 2011

 i need winrar and cannot to set up. you are sending me from one to  other page. i  work on computer a little,  english a little and cannot understand mooving of it.
@bstefans...: I don't understand.  Are you still seeing this bug in Chrome 8?  It shouldn't be bothering you anymore (except in some pretty rare situations).

Hi, I was directed here from  issue #45641 

It was mentioned that this could still happen in rare cases if CreateDirectory() fails.  I'm assuming anti-virus software could also cause this function to fail.

A recent update to our Symantec policy seems to trigger this bug for me when attempting to download .exe, .dll. or .msi files.  I'm on Chrome 9.  These files download correctly in IE.
@ra.rocha...: Just confirming that this is happening for you with a default downloads folder that doesn't exist (as per the original report).  If not, this is probably not the same bug, but can you answer the following questions:
* Did the download show up as a "dangerous download" (i.e. the item on the download shelf requesting confirmation from you that it should be downloaded)?
* Did Chrome prompt you where to save the file, showing "uncomfirmed %d.crdownload" as the default filename to pick?

If so, can you check to see whether that directory exists after the failed download?  If not, that is probably this bug (i.e. your Symantec policy prevented the directory creation in some fashion).

Do you know what the Symantec policy update did?  

After some more testing I think this is just a strange interaction with our new Symantec update.  I believe the Symantec update was a new Anti-Malware policy included with MR2.  It looks like it prevents downloading executables to the user's "Documents and Settings" folder because if I try to download the same files to my root D:\ drive they download correctly.

Also, although it originally appeared to work in IE, my default download location was to a path not under "Documents and Settings".  When I attempt to download an EXE in IE to a folder under Documents and Settings, I get an "access denied" error message.

To answer your questions...

* Yes, I was prompted to confirm the download.

* No, Chrome did not prompt to specify the location and the default filename displays the real filename and not "unconfirmed %d.crdownload".  The file appears to download successfully (instantly) but when I display the folder I see "unconfirmed %d.crdownload" instead of the file I am expecting.  When I set the option to ask where to save each file instead of auto-downloading, the resulting filename is "%s.tmp" where %s appears to be some hex number.  In either case, this is only if the download location is under "Documents and Settings".

If there is any change necessary, I would say the user should get an indication that the file did not download correctly.  Right now, the current behavior is confusing as I don't get any indication that there was a problem other than the cryptic filename.  Do you want me to open a new bug/feature request?

Comment 18 by alin@chromium.org, Feb 18 2011

Labels: ConOps
@ra.roche...: Yeah, if you could open a new bug, that would be good; this doesn't appear to be the same as the one being tracked in this issue.  We know that the downloads system have problems around detecting and reporting failures, and we're aiming to work on those problems in the next couple of months.  But having a bug specifically for anti-virus blocking writes to specific directories would help us cover all the bases with that work.  

Thanks in advance ....

Labels: -ConOps Hotlist-ConOps
This just started for me today, i had four downloads going, i know they didnt have much time left at all, (in fact, i think a couple of them had a less then a minute) but when I came back hours later they all said 'Interrupted' and had .crdownload added to their extension...these files still show up in 'Downloads' on chrome but have disappeared from my download folder...I really just want to find these files and change the extension so I can watch them...but I can't find them...even after searching for them and making hidden files visible...so frustrating! 
Summary of believed failure mode, just so I don't have to reconstruct it the next time I come back to this bug :-}: All dangerous downloads have an intermediate file name of "Unconfirmed %d.crdownload", which for historical reasons is stored in the same place in the various download type structures that the final filename for non-dangerous downloads is stored.  Currently, if we decide we're going to prompt the user for a download, we consider the file to be of a non-dangerous file type , since the user's going to see that it's a .exe/.dll/.dmg/.dangerous and have to confirm the save.  However, if the file is marked "prompt for location" after the dangerous/non-dangerous decision is made, we may be in a position where we are prompting for a dangerous download, and if we do so, we show the "Uncofirmed %d.crdownload" name.  This can happen if the path to which the download would be written by default is not writeable after we attempt to create it.  This code is in ChromeDownloadManagerDelegate::CheckIfSuggestedPathExists, near the top.
This has just started for me today: version 17.0.963.0-dev

The download folder exists, I checked and confirmed. Also tried changing it to a different folder (like c:\temp).
The only way I could make it go away is if I clear the checkbox that says "Ask where to save each file before downloading". Then it downloads the file as usual, without changing the name/extension. 

I can confirm that this is happening with *.exe but not with *.jpg.
Cc: asanka@chromium.org
@adil.hindistan: You're running into  issue 106194  (though the fix for that issue might fix this one).

CCing Asanka on this issue so he can make a judgement as to whether the 106194 fix (when it goes in) fixes this issue.

Just confirming that #23 is experiencing  issue 106194 .
I'm ALSO confirming #23's comment ... please fix this.
Asanka: Would you expect this problem to be fixed from your fix for the SafeBrowsing/File chooser pathway in MS-17?

rdsmith: This should be fixed in M17.

All: I'm closing this bug as fixed.  If you see this in a chrome version 17 or above, please file a new bug.  16 or below, I think you just have to wait :-{.
Status: Fixed
Blocking: -68198 chromium:68198 chromium:68198
Project Member

Comment 32 by bugdroid1@chromium.org, Oct 13 2012

Blocking: -chromium:68198
Labels: Restrict-AddIssueComment-Commit
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member

Comment 33 by bugdroid1@chromium.org, Mar 11 2013

Labels: -Feature-Downloads Cr-UI-Browser-Downloads

Sign in to add a comment