Closed Bug 958899 Opened 11 years ago Closed 11 years ago

Under Windows, cannot use a root directory as the destination for downloading

Categories

(Toolkit :: Downloads API, defect)

Product:
Toolkit
Component:
Downloads API
Version:
27 Branch
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED FIXED
Milestone:
mozilla30
Tracking Flags:
Tracking Status
firefox27 --- wontfix
firefox28 + verified
firefox29 + verified
firefox30 + verified
firefox-esr24 --- unaffected

People

(Reporter: mandelake, Assigned: Paolo)

References

Details

(Keywords: regression)

User Agent: Mozilla/5.0 (Windows NT 6.1; rv:27.0) Gecko/20100101 Firefox/27.0 (Beta/Release) Build ID: 20140109165205 Steps to reproduce: Since upgraded to beta build of Firefox 27, Firefox ignores the downloading path I've previously set, unless I specify a directory on that drive. Before, I used solely the drive D:\ as saving location and now, I get them each time saved on the Desktop. 1. On a new profile, Tools → Options → General tab → Downloads → select "Save files to..." → D: (it's the default for me). 2. Click to download a file from internet and it is saved each time on the Desktop. Actual results: Download a file. The file ends up on the Desktop, unless I specify a directory for "Save files to" on that drive. Expected results: Download a file. If chosen, the file should end up in the root structure of the desired drive and not be tied to a folder.
This is the second bug I've seen filed about the save location of downloaded files in a short timespan (see bug 958591). Paolo, are we aware of an/this issue here?
Flags: needinfo?(paolo.mozmail)
I reproduced this locally by selecting the root directory of the drive as the download target. David, is it possible that this is a bug with the ignoreExisting parameter on OS.File.makeDir, that is actually causing an error when called on a root directory on Windows? http://mxr.mozilla.org/mozilla-central/source/toolkit/components/jsdownloads/src/DownloadIntegration.jsm#410
Flags: needinfo?(paolo.mozmail) → needinfo?(dteller)
Status: UNCONFIRMED → NEW
Component: Untriaged → Download Manager
Ever confirmed: true
Product: Firefox → Toolkit
Note that the issue occurs with both "D:" and "D:\" configured in the about:config preference (the UI sets the preference to "D:").
You are correct, Paolo. We ignore existing directories by catching ERROR_ALREADY_EXISTS. However, when we try to create a root directory, Windows returns ACCESS_DENIED. I'm not sure there is a good way to fix this on the OS.File side. Is there a way to do it on the Download side?
Flags: needinfo?(dteller)
Keywords: regression
Summary: Firefox 27 ignores the preset downloading path → Under Windows, cannot use a root directory as the destination for downloading
(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #4) > You are correct, Paolo. > We ignore existing directories by catching ERROR_ALREADY_EXISTS. However, > when we try to create a root directory, Windows returns ACCESS_DENIED. I'm > not sure there is a good way to fix this on the OS.File side. Hm, could we detect at the OS.File level that we are requested to create a root directory (from the path string), turn that into a single call to "exists", and fail only if the drive letter does not exist?
For the record, this bug first appeared when we switched the API to get the directory name in bug 875731, though the problem is in the underlying API and not in the code that was changed there.
Blocks: 875731
Depends on: 960962
The bug is present on Firefox 27 final. Firefox 27 cannot save files to any root directory by default, except for Windows drive root directory. Firefox 26 and earlier could. Lots of people will find out the hard way about this bug starting today. I hope it gets fixed and 27.0.1 gets released as soon as possible with this bug fixed in it.
Here is a Thread but not much response yet http://forums.mozillazine.org/viewtopic.php?f=38&t=2798447
We believe that we have found the issue. The fix is in progress (see the list of blockers on the top of this page).
Whiteboard: p=0
why isn't this fixed yet? it's annoying as hell
This bug was not fixed in just released Firefox 27.0.1 Does this mean that the fix is still 'in progress' or did the initial idea on how to fix it not work?
The fix should arrive in Firefox 28. As a rule of thumb, we only fix critical bugs in .0.1 versions (bugs that completely mess with the user experience or that cause security or privacy issues) – recall that landing a bug fix directly in a .0.1 version means that we do not have time to test it properly, so this should be reserved to high-emergency issues.
(In reply to E B from comment #17) > This bug was not fixed in just released Firefox 27.0.1 > > > Does this mean that the fix is still 'in progress' or did the initial idea > on how to fix it not work? David already answered you, but I'd like to add that you can test that the fix works by using beta 3 from, http://ftp.mozilla.org/pub/mozilla.org/firefox/releases/28.0b3/ . 28 is scheduled to hit the release channel in about 4.5 weeks.
I just installed 28b3 and it still has the same problem.
This bug is also not fixed in latest Nightly m-c win32 build running on win7 x64, I don't see that its even landed on m-c as yet..., or anywhere for that matter.
There is not patch attached to this bug, so that isn't unexpected. @Gijs Is this being worked on in another bug, as far as you know?
(In reply to Francesco Lodolo [:flod] from comment #22) > Is this being worked on in another bug, as far as you know? I should check the dependency tree before asking the obvious. Bug 960046 is fixed and landed a few days ago on central, according to bug 960962 comment 11 that bug is not actually a blocker anymore, so it *should* work on a current Nightly, but it doesn't (30.0a1 2014-02-14).
Are you using the exact same steps as comment 1?
Flags: needinfo?(paolo.mozmail)
Flags: needinfo?(francesco.lodolo)
Assuming someone will come back to update the status of this tracked bug now that bug 960046 is landed. Anything else to do here?
(In reply to David Rajchenbach Teller [:Yoric] (please use "needinfo?") from comment #24) > Are you using the exact same steps as comment 1? 1. Create new profile (Win 8.1 x64) 2. Set Nightly to save downloaded files in D: 3. Save a file No question asked, in my case the file is saved to $userprofile\Download, not Desktop. If I set a specific folder on D: (e.g. D:\test), it works as expected.
Flags: needinfo?(francesco.lodolo)
Paolo, can you take a look?
I think the bug is caused by the commit http://hg.mozilla.org/mozilla-central/rev/738417678451
For those of us waiting for Beta 4 - it has been released and this bug is still *not* fixed. Beta 4 of Firefox 28 still has this bug.
Depends on: 973931
The patch in bug 973931 should fix the issue.
Flags: needinfo?(paolo.mozmail)
Assignee: nobody → paolo.mozmail
Beta 6 of Firefox 28 and still no fix.
Fix in bug 973931 has landed 12 hours ago on beta, you should wait for the next beta release.
BETA 7 of Firefox 28 finally fixes this bug! *Thank you* Saving to root directories allows us to access downloaded files quickly as possible in order to test that the download is OK and/or rename it before moving it / creating the final storage folder for it. This super-fast computing 101. This was not a 'rare case' bug or some kind of a specific specialized feature. Thank you for fixing it. I hope final versions of future releases get delayed until a bug like this one gets fixed.
Marking as FIXED by bug 973931.
Status: NEW → RESOLVED
Closed: 11 years ago
status-firefox28: affected → fixed
status-firefox29: affected → fixed
status-firefox30: affected → fixed
Resolution: --- → FIXED
Target Milestone: --- → mozilla30
Marking verified fixed for Firefox 28 based on comment 37. E B, would you mind also checking the latest Aurora and Nightly builds to confirm this is fixed there?
status-firefox28: fixed → verified
Flags: needinfo?(edinkc)
Yes, I can test it. I downloaded Firefox 29 Alpha 2 and tested it to work. Firefox 28 Beta 8 also tested to work. The bug is definitely fixed as of Beta 7 of Firefox 28. Thank you again.
Flags: needinfo?(edinkc)
(In reply to E B from comment #40) > Yes, I can test it. I downloaded Firefox 29 Alpha 2 and tested it to work. > Firefox 28 Beta 8 also tested to work. The bug is definitely fixed as of > Beta 7 of Firefox 28. Thank you again. Sorry, I just downloaded and installed Firefox 28.0b8 in French version http://www.mozilla.org/fr/firefox/beta/. The bug is not fixed : I can't choose the directory where I wish to download. Is the English version, as original language, different from the other versions ? Many thanks to all the contributors who are working on this issue.
Flags: needinfo?
(In reply to hd3 from comment #41) > Sorry, I just downloaded and installed Firefox 28.0b8 in French version > http://www.mozilla.org/fr/firefox/beta/. The bug is not fixed : I can't > choose the directory where I wish to download. Is the English version, as > original language, different from the other versions ? Many thanks to all > the contributors who are working on this issue. The original issue in comment 0 is fixed on my system by the version of Firefox that you referenced. In case a different issue occurs for you, can you please file a new bug report, providing detailed steps to reproduce? Thanks!
Flags: needinfo?
Marking this verified fixed based on the testing done so far. As Paolo mentioned above, please file a new bug if you can sill reproduce issues with this so we can investigate those separately. Thanks for the help everyone.
Status: RESOLVED → VERIFIED
status-firefox29: fixed → verified
status-firefox30: fixed → verified
No longer blocks: fxdesktopbacklog
Whiteboard: p=0
Sorry, because it is difficult for me to better explain : I am bad English speaking - being French (nobody's perfect !) - and I am not a specialist... Yesterday, I downloaded and installed the final 28.0 version (in French language) and I always got the same problem : 1) I click Outils>Options and go to the Telechargements section 2) if I choose "Enregistrer les fichiers dans le dossier" and click Parcourir, nothing will happen. That is, no choice appears. 3) if I choose "Toujours demander où enregistrer les fichiers", then nothing happens (nothing is asked) when I download my file and I don't know where it is downloaded. That is why I say that the bug is not fixed... and why I always use the 25. version...
Flags: needinfo?
(In reply to hd3 from comment #44) > nothing happens (nothing is asked) when I download my file and I don't know where it > is downloaded. Please file a new bug report and provide these steps to reproduce. Thanks.
Flags: needinfo?
You need to log in before you can comment on or make changes to this bug.