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

Status: VERIFIED FIXED

(Toolkit :: Downloads API, defect)

Description

[mandelake]

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.

Comment 1

[:Gijs (he/him)]

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?

Comment 2

[:Paolo Amadini]

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

Comment 3

[:Paolo Amadini]

Note that the issue occurs with both "D:" and "D:\" configured in the about:config preference (the UI sets the preference to "D:").

Comment 4

[David Teller [:Yoric] - still alive but not very active]

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?

Comment 5

[:Paolo Amadini]

(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?

Comment 6

[:Paolo Amadini]

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.

Comment 8

[E B]

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.

Comment 9

[softskiller]

Here is a Thread but not much response yet http://forums.mozillazine.org/viewtopic.php?f=38&t=2798447

Comment 10

[David Teller [:Yoric] - still alive but not very active]

We believe that we have found the issue. The fix is in progress (see the list of blockers on the top of this page).

Comment 13

[tazz_]

why isn't this fixed yet? it's annoying as hell

Comment 17

[E B]

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?

Comment 18

[David Teller [:Yoric] - still alive but not very active]

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.

Comment 19

[:Gijs (he/him)]

(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.

Comment 20

[Timo Jarvenpaa]

I just installed 28b3 and it still has the same problem.

Comment 21

[Jim Jeffery not reading bug-mail 1/2/11]

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.

Comment 22

[Francesco Lodolo [:flod]]

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?

Comment 23

[Francesco Lodolo [:flod]]

(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).

Comment 24

[David Teller [:Yoric] - still alive but not very active]

Are you using the exact same steps as comment 1?

Comment 25

[Lukas Blakk [:lsblakk] use ?needinfo]

Assuming someone will come back to update the status of this tracked bug now that bug 960046 is landed.  Anything else to do here?

Comment 26

[Francesco Lodolo [:flod]]

(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.

Comment 27

[David Teller [:Yoric] - still alive but not very active]

Paolo, can you take a look?

Comment 31

[xunxun]

I think the bug is caused by the commit http://hg.mozilla.org/mozilla-central/rev/738417678451

Comment 32

[E B]

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.

Comment 33

[:Paolo Amadini]

The patch in bug 973931 should fix the issue.

Comment 34

[E B]

Beta 6 of Firefox 28 and still no fix.

Comment 35

[Francesco Lodolo [:flod]]

Fix in bug 973931 has landed 12 hours ago on beta, you should wait for the next beta release.

Comment 37

[E B]

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.

Comment 38

[:Gavin Sharp [email: [e-mail]]]

Marking as FIXED by bug 973931.

Comment 39

[u279076]

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?

Comment 40

[E B]

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.

Comment 41

[hd3]

(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.

Comment 42

[:Paolo Amadini]

(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!

Comment 43

[u279076]

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.

Comment 44

[hd3]

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...

Comment 45

[u279076]

(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.