400076 - /tmp-1 could not be saved, because you cannot change the contents of that folder.

Status: VERIFIED FIXED

(Firefox :: File Handling, defect)

Description

[Tuukka Tolvanen (sp3000)]

linux firefox trunk 2007-10-13-19Z

        Downloading /tmp-1

        /!\ /tmp-1 could not be saved, because you cannot change the contents
            of that folder.

            Change the folder properties and try again, or try saving in a
            different location.

                                                                        [OK]

case one: at https://bugs.maemo.org/show_bug.cgi?id=693#c7 middle click attachment

case two: at http://tablets-dev.nokia.com/d2.php left click on rootstrap_..._v2.2 (it probably wants you to click a button or such to set a cookie first)

not readily reproducible.

Comment 1

[Dennis Jacobfeuerborn]

I've seen this a couple of times too in the last few days. Usually trying to download the file again fixes the problem when it occurs.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007101704 Minefield/3.0a9pre

Comment 2

[Reed Loden [:reed]]

I see this, too.

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007102004 Minefield/3.0a9pre

Comment 3

[Dan Mosedale (:dmosedale, :dmose)]

I'm having trouble reproducing this.  The steps to reproduce here are pretty vague.  Can you post in fairly explicit detail exactly the list of actions / clicks that leads to this error?  In particular, I'm trying to understand if/how the filepicker is involved here.

Comment 4

[Bob Clary [:bc] (inactive)]

I can usually reproduce it by setting "Always ask where to save files", then initiating several downloads in sequence. Usually, the 2nd or 3rd simultaneous download will result in the /tmp-1 error instead of the file picker.

Comment 5

[Mike Beltzner [:beltzner, not reading bugmail]]

Blocking for investigation ... can someone figure out what's causing this, please?

Comment 6

[Ed Lee :Mardak]

This should be fixed by bug 402298.

Comment 7

[Hideo Oshima]

(In reply to comment #6)
> This should be fixed by bug 402298.

I tried to download files many times
but I can't reproduce with today's build.
I think this is fixed too.

Comment 8

[Ed Lee :Mardak]

-> Fixed per comment #7.

If there's a general download litmus testcase per platform, this could work well for linux as on other platforms, the parent of the temp directory is generally user writable. "download a bunch of open-with files" (On linux, does the error show up right away during/before the open-with dialog? That could simplify testing if the user can just start and cancel downloads instead of waiting for them to finish.)

Comment 9

[Stephen Donner [:stephend] Not actively reading bugmail]

My brother Jeff emailed me a few days ago, telling me he experienced this bug on a daily basis, and that the recent nightlies (running under Ubuntu Linux) have indeed fixed this.

My own testing--and others--confirms this to be true, using:

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9a9pre) Gecko/2007110604 Minefield/3.0a9pre

Verified FIXED