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.

probably a dup.

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

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.

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.

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 ***

marking verified as a duplicate. if you decide to reopen this bug, please clarify why. search string for bugspam removal: SalviaGuaranitica