Failed downloads on Windows 7 with Folder redirection and Windows offline files disabled |
||||||||
Issue description
Chrome Version : 51.0.2704.79. Issue was first noticed on 49, but it can be reproduced on current Canary build.
Other browsers tested: Firefox and IE.
Add OK or FAIL, along with the version, after other browsers where you
have tested this issue:
Safari:N/A
Firefox:OK 46.0.1
IE:OK 9.0.8112.16421
What steps will reproduce the problem?
(1) Configure Windows folder redirection for "Desktop, My Documents, Downloads, and Favorites". https://technet.microsoft.com/en-us/library/cc732275.aspx
(2) Configure Chrome's Default downloads location pointing to any of the redirected folders in a network share.
(3) Manually Disable Offline Files through the Windows Sync Center.
What is the expected result?
-Chrome should be able to save files to the configured downloads location.
What happens instead?
-You get error: "Failed - Download Error".
Please provide any additional information below. Attach a screenshot if
possible.
-The issue only happens when you disable Windows files offline. If you re-enabled it, downloads works as expected, even if the default downloads location points to a network share.
-Issue only happens on Windows 7. Tested on Windows 7 Professional SP1 x64 ,
-This configuration works fine on Windows 10.
-Tested with Windows Server 2012 R2. Our customer had a similar configuration with Windows Server 2008 R2, and it worked as expected.
-Issue on happens with certain type of files. He confirmed issues downloading PDF and xlsx files. This doesn't affect Zip files.
-Unable to reproduce the issue if Chrome is configured to prompt for a downloads location and manually saving to the redirected folder.
-If default downloads location is configured pointing to another network share location outside the redirected folders, everything works.
-Unable to reproduce the issue while signed in as a Windows Admin Account.
-This configuration works fine with other browsers.
Basic troubleshooting like clearing cache and cookies, disabling extensions, antivirus, and incognito mode did not change the behavior.
---------------------------------------------------------------
This was initially reported at crbug.com/383765 but it was closed before the behavior was defined, and the real root cause found. This is pointed in later comments from users.
It appears this only triggers on folders with localized names within the Desktop.ini file. This can be removed by running the command $(Get-Item "Downloads").Attributes = 'Directory' on each folder, but this also removes the folder icon.
Screenshots and related logs can be found at https://drive.google.com/a/google.com/folderview?id=0BzWUz38-X_A9bHNZTF9FcEJlODA&usp=sharing (Google.com Signed in required)
I will look forward to your comments on this issue.
,
Jun 7 2016
Justin: Summoning you for Windows Brain Trust folks as to why the what this wouldn't work.
,
Jun 8 2016
+wfh@ I'm baffled. Maybe ping it to chrome-windows internally and see if anyone has any idea?
,
Jun 8 2016
Could you send us a net-internals log as described in https://sites.google.com/a/chromium.org/dev/for-testers/providing-network-details ? This should give us a more specific error and hopefully some more details about the sequence of events preceding the error.
,
Jun 8 2016
I can see if I can repro
,
Jun 8 2016
,
Jun 8 2016
Meanwhile, can you try and reproduce the issue yourself, then go to chrome://histograms and send you the entire contents of the "Download.MapWinShErrorFileFailed" histogram data? Also, can you start Chrome manually with the following switches appended: --enable-logging=stderr > log.txt 2>&1
,
Jun 8 2016
... and then attach log.txt to this bug.
,
Jun 23 2016
llinares: Could you please provide us with the requested information?
,
Jun 28 2016
@wfh I apologize, it was not clear for me if you were requesting that information from me. I actually don't have the environment to reproduce this behavior. However, I can request our customer for this logs, but let me know what switches exactly they will need to add, as the --enable-logging=stderr switch did no return any logs.
,
Jun 29 2016
Thank you for providing more feedback. Adding requester "asanka@chromium.org" for another review and adding "Needs-Review" label for tracking. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 8 2016
Are there any updates on this?
,
Jul 14 2016
,
Aug 26 2016
This case currently has no owners. Will this be assigned?
,
Oct 25 2016
Gentle Ping! There is no update on this issue since 2 months, could any one let us know what's the current status of the issue? Thanks!
,
Dec 8 2016
llinares@: #4 and #7 need your feedback.
,
Jan 10 2017
We haven't received the feedback needed to make further progress on this bug. Closing as won't fix. Please feel free to reopen if you have the requested information. |
||||||||
►
Sign in to add a comment |
||||||||
Comment 1 by llinares@chromium.org
, Jun 3 2016