72555 - OS/2 - Downloading fails to write to disk

Status: VERIFIED FIXED

(Core :: Networking: File, defect)

Description

[bamford]

Downloading does not work.
The normal download dialog appears and the progress meter works
normally, but no file appears at the destination, or anywhere else.
Tried for different types zip txt etc. Both http and ftp sites.

I am using ECs preview 1, everything else works fine so far. Better
than NS4.61

Dave Bamford

Comment 1

[Kunihiko Aizawa]

I have same problem on my home PC.
I noticed that the downloaded file was stored into %tmp% (d:\tcpip\tmp)
with temporary file name.
For example, I tried to download
http://www6.big.or.jp/~misao/files/os2/wlsync/wls09999.zip
into f:\download, then I got d:\tmpip\tmp\zx27tlpn.zip.

My office PC doesn't have this problem.
So I copy all Warpzilla stuff including user prefs from office PC
to home PC then I try the downloading again, but the symptom is
still on home PC.

Both PC have same OS (OS/2 4.51 JP), same disk partitioning and
same directory structure. I cannot figure out what the problem
depends on.

Comment 2

[timeless]

i'm assuming that is _not_ the same problem (reporter please correct me if i'm 
wrong), the reporter indicated that nothing was written to disk.  Yes we use a 
temp directory (controlled by a bunch of env vars) to decide where to stick 
files before writing to final output. The reason is discussed in other bugs (we 
actually start the download before you decide where you want us to put the 
file).

Comment 3

[aaronr]

The problem here is that we are doing a DosMove inside
nsLocalFile::CopySingleFile().  On my machine, when this fails, it is because my
TMP environment variable is set to a drive that isn't the same as the drive that
I am trying to save to.  Thus, the DosMove fails with ERROR_NOT_SAME_DEVICE and
the file isn't copied.  If I set TMP=H:\TMP before starting mozilla and then try
to save the file to h:\temp\wls09999.zip, then the save works.  That explains
why it works for Kunihiko at work but not at home.

I'll fix this.

--Aaron

Comment 4

[aaronr]

Attachment: patch to fix bug 72555

Comment 5

[aaronr]

The fix I did was to do the DosMove and if it failed 
because the items weren't on the same disk, then use the 
copy code to copy the source file to the target and then 
delete the source file

--Aaron

Comment 6

[Dmitry Kubov]

duplicate of 66476 ?

Comment 7

[Kunihiko Aizawa]

Thanks Aaron, I also be able to avoid the symptom by setting %tmp%
to a drive which Mozilla is on. I don't have an environment to build Mozilla
from source then I will await a new nightly your fix.included be available.

Dave, is your problem same as mine?

Comment 8

[aaronr]

Attachment: better patch for 72555

Comment 9

[aaronr]

Sorry to do this again, but it was pointed out to me that my code
could be more efficient.  So I attached a reworked fix for this
bug.  Same logic, just changed it so that I didn't duplicate the
copy code in the case of a move, but rather in the case of a move
to try the move first and if that failed, then fall into the copy
code that was already there.  And, of course, if it was a move I
added a DosDelete at the end of the old copy code.

--Aaron

Comment 10

[Mike Kaply [:mkaply]]

Definitely a bug. Will checkin when the tree opens.

Comment 11

[Mike Kaply [:mkaply]]

Fix checked in

Comment 12

[Dmitry Kubov]

Why trashing hard disk?
Why not saving to target dir like NS 4.x w/o TEMP?

Comment 13

[Dmitry Kubov]

I'm talking about bug 69938

Comment 14

[Dmitry Kubov]

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

Comment 15

[Mike Kaply [:mkaply]]

Verified - this is fixed