Closed Bug 82478 Opened 23 years ago Closed 23 years ago

FTP: download silently fails if final destination is full

Categories

(Core Graveyard :: File Handling, defect)

Product:
Core Graveyard
Component:
File Handling
Platform:
x86
Linux
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(Not tracked)

Status:
VERIFIED DUPLICATE of bug 65770
Milestone:
mozilla1.0

People

(Reporter: tom, Assigned: law)

References

Details

Hi,

Using Redhat 6.2 RPM of Mozilla 0.9, build id: 2001050717 which I downloaded and
installed from mozilla.org.

This bug happens when downloading a large file with FTP. There are what I would
consider three related parts to the bug.

a) If /tmp fills up during the download, the download continues without error or
warning and a corrupted file will finally be saved in your choosen download
directory (again without warning).

b) If I select to download into /home/user which has enough space, there should
be no need to rely on /tmp having enough space also and the file should be
downloaded directly to that location.

c) A size check should be done before doing the download to ensure that it will
fit on the disk as a precaution for the user. Granted depending on how otherwise
busy the machine is Mozilla should still be able to detect a full disk.

Thanks,

Tom.
The bug is clearly related to bug 57902, bug 49868 & bug 32443. However, I do
not think it's a dup of any of them (they are mostly mail&news download
problems). There should be a meta bug on low disk space problems (already
acknowledged in the release notes).
Confirming on WinME. Actually then the opposite is true (the partition with the
TEMP directory can accomodate the file but the target partition does noot have
enough free space) FTP also fails without a warning. The actual result: the file
remains in the TEMP directory, no file appears in the target directory, no
warning whatsoever.
Status: UNCONFIRMED → NEW
Ever confirmed: true
probably a dup.
Assignee: dougt → law
*** Bug 95969 has been marked as a duplicate of this bug. ***
Keywords: mozilla1.0
Depends on: 100687
qa to me.
changed summary to reflect second problem

Thomas: I'm hijacking your bug and turning it into the second of the two 
problems discussed here. The problem you originally described is now tracked in 
the dupe (which I've re-opened).

re: usage of tmp at all, this is a somewhat hottly debated feature/behavior, esp 
since it is not Xplat friendly in all uses. I wish I could resolve that point 
for you easily, but I cannot.
QA Contact: tever → benc
Summary: No error on disk full when downloading a large ftp file. → FTP: download silently fails if final destination is full
Just a suggestion, but if the user selects to save the file as
/home/tom/verybigfile.dat why not start saving it under /home/tom as
verybigfile.dat or a temporary name like .moz_verybigfile.dat. In the second
case it could then just move the file to the new name if it worked (which would
be very fast and the expected behaviour?), whereas now it would download into
/tmp (probably a different partition) and the file move would involve copying
all the data from /tmp to /home/tom which would mean a busy disk if the file is
big. Downloading into /tmp particularly when a user suggested a place to store
the file in the first place just seems a bit wrong to me. This would also be
platform independant, no?
This is really 3 bugs.  There are already bugs for the first 2 (although the
fact that 27609 is a dup may not be obvious).

a: bug 27609

b. bug 55690 

c. has come up before but I can't find a bug on that right now.  I suggest
changing this bug to an RFE for that specific issue.  But it's not my bug so I
don't want to do that unilaterally.
Target Milestone: --- → mozilla1.0
Thomas: things in this area are pretty complicated... I wish I could point you
to one place to get all the info...
I think bug 55690 is the right place for the suggestion to go.

BTW, my comment was really a request for the reporter to examine the other bugs,
convince themselves that problems a. and b. were covered elsewhere, and to
modify this bug to be a request for the feature c.

Note that until 55690 settles out, it might be a little difficult to implement
that feature.  As it stands now, we'd have to check 2 destinations for
sufficient space and I don't want to try to figure out what kind of alert to
show if it fails one but not the other.
Bill and Benjiman: I agree that parts a) and b) are a dup of 55690. I see that
it has been hotly debated :) As for part c) after reading through the full 55690
bug, I think I'd rewrite it as the following. I'm not sure how you guys want to
handle this, Ie if you want to me write up a new bug and mark this one as a dup
or something, but here is what I would replace c) with.

1. User selects to download file somefile.iso in /home/tom.

1a. If file somefile.iso already exists, offer to replace/resume or cancel.
Replace would restart the file at location 0 and resume would do a fileseek to
the end of the locally stored file and request bytes after that from the server.
(This is supported by most modern ftp servers and http servers???).

1b. If resume fails because the server can't implement it, then tell the user
that the the server doesn't support it and offer to Replace or Cancel the download.

2. Moz makes a quick check on the diskspace it thinks is available in /home/tom
and if Moz thinks the download will run out of space, it should pop up a dialog.

2a. The dialog should warn the user what is happening and offer to a) Continue
the dowload to original location regardless, b) select another location (go back
to 1) or c) cancel downloading.

3. The download should continue to location selected by user. If read()/write()
fails at any point (ie connection broken/disk/quota full etc), the user should
be told that an incomplete download is available at location
/home/tom/somefile.iso and a summary of what happened. It should also tell the
user that they can resume the download later, by downloading the file again.
From point 1 where they would get to point 1a.

I think this is what most people would want, and it is also a good reason not to
download to a location before a user has selected the location unless it is a
user default download directory as a preference (not a user default temporary
directory). It is also a good reason to download to the correct final filename
rather than using a temporary one.

Bill: 

Are you the only person that uses temp files? If not, there might be a need to
standardize access for temp space among all consumers (mail, NIM, etc). Since
different OS's handle temp space differently, a standard approach might be
useful. (Then you wouldn't have to worry about doing the alerts, it would be
part of that service).

Thomas: good points. We'll have to try to get all the design issues together
after this release.
personally i'd prefer to get only one dialog in the case the server doesn't 
support resume.

This server does not support resume, would you like to replace the file.
> Are you the only person that uses temp files?

That's kind of like the "Have you stopped beating your wife?" question.  I don't
know if the uriloader/exthandler code is the only such code in Mozilla.  I think
all such issues should be resolved in context of bug 55690.

Thomas: Your steps are incompatible with the way things currently work and imply
a particular resolution to bug 556990.  I think it is problematic to intertwine
bugs in such a way.  Can we modify this one so that it is independent of that
other bug?



Bill: I'm from mars. What's a wife? What's a beat?

I think it's a given that some people are going to want to do a fast-start
download to their OS specified temp directory. We need something that is
flexible to handle different configs. This probably affects ANY feature that
uses temp space, but since you download the biggest files, you get the most
attention... 
>Bill: I'm from mars. What's a wife? What's a beat?

I was just trying to duck the accusation that it was *me* (or my code) that was
using any temporary file.  But that's neither here nor there.  I stand by my
attempt to get that issue (of consolidating access to temporary files) moved to
bug 55690 (that deals with the whole issue of using temporary files).

This bug has to either be focused on something concrete and specific, or it will
never get fixed.


What's a duck? :)

From the perspective of FTP QA, at this point, I just want an error message. 

I've made comments in several places about how I think it *should* work, but
I'll deliver something coherent after we get through this release cycle...
*** Bug 95969 has been marked as a duplicate of this bug. ***
c. is now bug 65770

Closing this one as dup.  Take up the individual issues in the appropriate 
places.

*** This bug has been marked as a duplicate of 65770 ***
Status: NEW → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Component: Networking: FTP → File Handling
QA Contact: benc → sairuh
marking verified as a duplicate.

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

search string for bugspam removal: SalviaGuaranitica
Status: RESOLVED → VERIFIED
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.