84197 - download of file doesnt relocate temporary file to correct destination

Status: VERIFIED DUPLICATE of bug 85115

(Core Graveyard :: File Handling, defect)

Description

[Dave Booth]

File download from the above site uses ftp://.... URLs.

As expected when one is selected the dialog pops up prompting what to do with it
and I select "save to disk" and specify a location.

After download completes file is not there.

Investigating further I noticed that in the download progress dialog a pretty
typical temporary filename was listed as the destination for the file (for
example /tmp/lad5mtfq.gz ) instead of the location I specified.

Knowing that mozilla begins the download in the background whilst asking where
to put the file I looked for that temporary file and it was indeed the file I
was intending to download, it had just never been relocated to the destination I
specified after the download completed.

First noticed on a nightly build that was a few days old, downloaded latest
nightly and its still there.

Comment 1

[Doug Turner (:dougt)]

and I know how much you love these bugs. :-)

Comment 2

[Chase Tingley]

Attempting to confirm on linux.  1.6k/sec throughput from this site.  Whoo.

Comment 3

[Chase Tingley]

Downloaded two files with 2001060506/Linux, no problems.  Platform issue?

Comment 4

[Dave Booth]

Details of the platform on which I see the bug...
Sun Ultra5, 64 bit Solaris 8, current security & recommended patch cluster

I've tested it this morning on http file downloads too and its there as well..
I went to grab http://ftp.mozilla.org/pub/mozilla/nightly/latest/mozilla-
source.tar.gz and the same error occurred - the file ended up 
as /tmp/q4rqfuf4.gz instead of /export/software/source/mozilla-source.tar.gz

I'm going to make another attempt to get it to build on my system and see if a 
locally built copy works but I've had problems building the lizard with gcc on 
this box so dont hold your breath - thats why I download nightly binaries :/

Comment 5

[timeless]

can you run truss or something to see if a move operation of some sort is 
failing?

Comment 6

[Bill Law]

There was recently a very, very similar bug report on OpenVMS.  The problem was
due to some file system quirk relating to mv'ing files across volumes or some such.

My guess is something similar going on here.  It needs to be debugged by
somebody running on this, or a similar, system.  The code in question is in
nsILocalFilexxx (for whatever xxx applies to Solaris).

This shouldn't be my bug.  I'm going to reassign to mscott (sorry for passing
the buck, but at least I'm passing it in the right direction, I think).

Comment 7

[Bill Law]

The OpenVMS bug was bug 70915.

Comment 8

[Dave Booth]

From my earlier investigations it made no diff what filesystem I specified the 
destination in.. I tried it with both local and nfs-mounted destinations, in 
each case both ufs and vxfs fstypes. Of course I didnt test it trying to place 
the downloaded file in /tmp... I'm going to try and grab a few mins to attempt 
a truss to see if theres any visible errors but I'm a little busy fixing the 
problems I'm paid to address at the moment.

Comment 9

[Dave Booth]

Ok, got a truss done and will attach its output.

I modified the distributed run-mozilla.sh to truss the prog rather than just run
it and captured all output into a file so the usual status messages are in there
too. Session consisted of opening mozilla, letting my homepage load and then
going to ftp://ftp.mozilla.org/pub/mozilla/nightly/latest/ I downloaded
mozilla-win32.zip (just because it was a file I normally *wouldnt* get) and
specified my homedir as the place to put it. After the download completed quit
mozilla. File was downloaded to  /tmp/p07mv5mg.zip and there it remained,
nothing was added to my homedir.

Comment 10

[Dave Booth]

DOH! not a fair test... something else filled up my homedir whilst I was running
the truss.

I'll repeat now I've cleaned out the cruft.

Comment 11

[Dave Booth]

ok, truss repeated and output will be attached as trussmozilla.gz. All details
and outcomes same as last time except temp file name differs of course. I case
you're interested in this case it was /tmp/bajq0kss.zip.

Comment 12

[Dave Booth]

Attachment: gzipped truss output

Comment 13

[Matthias Versen [:Matti]]

related to bug 85115 ?

Comment 14

[mwehner]

Confirmed on Linux/2001070608 both with http and ftp links. All downloads are
left in /tmp with random Names and correct extension. No diskspace/permission
issues with the selected target dir.

I agree with Matti: seems to be the same problem as bug 85115. Platform = All?

Works with Linux/0.9.2 though. Regression?

Comment 15

[Dave Booth]

Confirmed similar behaviour to 85115. Right-click and choose "Save Link As..."
and problem does not occur.

Further info to help locating the problem:

When downloading by whichever method the download progess dialog shows accurate
info for the destination filename - ie where it is *really* going to end up.
Left-click and choose save to disk and the temporary filename shows in the
progress dialog and the file is never relocated to the destination you
specified. Right-click and save link and the progress dialog shows where you
specified to put it and thats where it goes.

Comment 16

[Keyser Sose]

Duping..for me creating a new profile fixed this problem.

*** This bug has been marked as a duplicate of 85115 ***

Comment 17

[sairuh (rarely reading bugmail)]

marking verified as a duplicate.

if you decide to reopen this bug, please clarify why.

search string for bugspam removal: SalviaGuaranitica