160608 - Downloaded files don't get copied to destination

Status: VERIFIED FIXED

(Camino Graveyard :: General, defect)

Description

[jail]

this is using chimera 0.4 official release. 
i download file's to a seperate hard drive, basically: download file to non-boot
disk, file download's fine, when i look in the folder i downloaded it too, it's
not there. after this dosn't work, i eventually tried downloading to my bood
disk. the file downloaded in a split second (ie, didn't download, just moved
from somewhere else, cache maybe) and the file is downloaded fully working. the
download window appears and disapears instantly, on a 56K modem, dwonloading a
1Meg file, "1.2 MB per second" :). has happened three times, with three
different urls, every time a tried to download to the seperate disk. this bug
was not in v0.3

sys stats:
os x 10.1.5
Beige G3 233Mhtz, 352 MB RAM
booted off 4Gig hd (chimera also on this drive.)
downloading to 40Gig drive failes.

Comment 1

[Greg K.]

WorksForMe using Chimera/20020801. Files downloaded to a non-boot volume
download completely successfully.

Comment 2

[Steve Smart]

I've had this happen many times (in 4.0 and nightly builds thereafter); it has
only occured when I was saving to a non-boot disk, and only when I downloaded by
single-clicking, not using the context menu.

The file was actually gone (not a Finder refresh problem; ls couldn't see it
either), but if I downloaded it again using the context menu, it would be
instantly loaded from cache, so the download itself was successful.

Comment 3

[saari (gone)]

the bug we discussed in macdev, there has to be a dup of this...

Comment 4

[Winnie Lam]

related to bug 159350 - Downloading fails with non-standard Users directory
location?

Comment 5

[Steve Smart]

159350 is exactly the problem with this that I have; if jail can confirm that on
his setup, I would say that this is a dup.

Comment 6

[Nicholas Riley]

I had the same problem, I downloaded a 53 MB file twice and wondered where it went.

This is not bug 159350: my Users directory is in the usual place (/Users/nicholas).

FWIW, the file I was trying to dwonload was the XonX install:

http://umn.dl.sourceforge.net/sourceforge/xonx/XInstall_10.1.sit

and the location I was trying to download it to was:

/Volumes/GrayExtra/Received/XInstall_10.1.sit

Where it ended up:

-rw-r--r--    1 nicholas wheel         54M Aug  4 22:45 /tmp/if0hq301.sit
-rw-r--r--    1 nicholas wheel         54M Aug  4 22:42 /tmp/rcxmzcl6.sit

Comment 7

[Mike Pinkerton (not reading bugmail)]

d/l issues -> conrad

Comment 8

[Chris Meiering]

Is this the same as bug #159792 ?

Comment 9

[Conrad Carlen (not reading bugmail)]

I see the problem:

If I download to /Volumes/OtherDrive/file.sit, it works.
If I download to /Volumes/OtherDrive/Stuff/file.sit, it fails.

Now, I know that, time to see what's happening in the debugger...

Comment 10

[Conrad Carlen (not reading bugmail)]

*** Bug 159792 has been marked as a duplicate of this bug. ***

Comment 11

[Conrad Carlen (not reading bugmail)]

What I said in comment #9 is 100% reproducible with 0.4 and also the nightly
from 08/06. It is not reproducible at all with my current debug build (with any
local changes to the file code removed)

Comment 12

[Simon Fraser [no longer active]]

Smells like a compiler bug (or a static build thing). I wonder if the same issue
is affecting the disk cache code?

Comment 13

[David Haas (gone, not reading mail)]

Well, I'm not sure if this should go here or another bug, but what the heck.

The "disappearing download" bug just bit me, too.  I was downloading to 
/Users/haasd/Desktop/Dec2001DevToolsCD.dmg.bin   The download finished, but no
file was there.   However, in /tmp , I've got a file (randomstring).bin , which
looks like it's the exact right size as the file I was downloading.

This machine has 1 HD & just 1 partition, so that's not the issue.

So it looks like the dl starts saving in /tmp & just never moves the file to
where it should end up.

Hope this helps.

Comment 14

[Conrad Carlen (not reading bugmail)]

> So it looks like the dl starts saving in /tmp & just never moves the file to
where it should end up.

Yes, that's exactly this problem. From the comments and what I have observed,
"disappear" is misleading - making summary more accurate.

See also bug 156250 which caused this when replacing an existing file. That
wasn't  fixed until 7/31.

Comment 15

[Conrad Carlen (not reading bugmail)]

Attachment: patch

nsLocalFile::GetParent() had 2 variations - one for DEBUG and not. The !DEBUG
case was broken. It turns out not to need two variations so I went with the one
that worked in both cases. Tested the reported problem as well as when building
new component.reg and xpti.dat.

Looking for review.

Comment 16

[Mike Pinkerton (not reading bugmail)]

Comment on attachment 94394 [details] [diff] [review]
patch

r=pink

Comment 17

[Simon Fraser [no longer active]]

It looks from the diff that you removed the entire method. Can you post one with
more context?

Comment 18

[Conrad Carlen (not reading bugmail)]

Attachment: with more context

Comment 19

[Conrad Carlen (not reading bugmail)]

This was fixed by checkin for bug 159987.
The problem that it fixes is the one where it wasn't possible to download to
"/Volumes/SomeDrive/SomeFolder/SomeFile.sit" The problem as reported in comment
#13 is something I have never been able to repro.

Comment 20

[Chris Petersen]

Verified in 2002-08-11-05 NB.

Comment 21

[Tuukka Tolvanen (sp3000)]

*** Bug 163383 has been marked as a duplicate of this bug. ***