GNOME Bugzilla – Bug 158780
Download manager does not notify when disk is full
Last modified: 2018-08-03 19:12:03 UTC
1. Fill a partition so only a few kb are left 2. Download a file larger than the partition can handle Expected behavior: either... (a) the file does not begin to download unless there is enough space, or (b) when the disk is full a notification is given (plus maybe an option to resume) Actual behavior: - The ".part" file is mysteriously deleted - The download manager looks as though the download is continuing, except the progress never changes. Pause/Resume don't do anything.
Somewhat related question: is it possible yet to plug an external downloader into epiphany?
See also https://bugzilla.mozilla.org/show_bug.cgi?id=65770 .
Created attachment 192714 [details] [review] e-download: warn when filesystem is full When a new download starts, we check the free space of the destination filesystem, if it's less than the reported full size of the download we show a GtkInfoBar warning the user. We don't try to be smart warning on "5%" free space or something like that. Let's just tell users why their downloads don't finish (or won't). Bug #158780
Was anybody able to review the patch ? Can patch be committed in master branch ?
Shouldn't we better check for this before starting the download and offer the possibility to save in a different location if there is not enough space? Just telling the user that there won't be enough space doesn't cut it imho.
(In reply to comment #5) > Shouldn't we better check for this before starting the download and offer the > possibility to save in a different location if there is not enough space? Just > telling the user that there won't be enough space doesn't cut it imho. Yes, but not in all cases the download size is known in advance. There needs to be a backup for that situation too.
I am working on this again. We have two main cases where downloads are started: links and save-as. Links are sent to ~/downloads automatically, so it is possible to check for enough free space on ephy_file_downloads_dir() every time a link triggers a download. The UI could be (ignore wording): | There is not enough space for $download on $directory-name. | | Free some space and try again. [Try again] [Cancel] | I am not sure where, or what, of the "computer lingo" we can allow ourselves in this dialog: hard-drive, disk, drive? What is the clearest way to say "disk is full, delete torrents". Save-as is different case because it triggers a destination selection. The only moment we can test for enough space is after the user accepts the selection, this means we can act on low space when response_cb of the dialog is called. This creates the question: What do we tell the user? Do we present the GtkFileChooserDialog again, plus a warning GtkInfoBar in the action-area? Do we use a GtkInfoBar in the main browser window? I think the new GtkFileChooserDialog with a GtkInfoBar is good enough for now. We could also add a custom widget to the GtkFileChooser that, on drive change, checks for available space and warns the user before saving. This sounds like something that could be in GTK+. Maybe we should get input from designers for this more complex fix. For the moment, I would like to get some agreement on the proposed solutions for both cases. We can research a GTK+ improvement later.
Clarification: (In reply to comment #7) > Links are sent to ~/downloads automatically, so it is possible to check for > enough free space on ephy_file_downloads_dir() every time a link triggers a > download. The UI could be (ignore wording): I do not mean to add a check inside that function. I mean that since we know the path, we can check the drive where that path is. The download does not start until the destination is approved as free enough. > | There is not enough space for $download on $directory-name. | > | Free some space and try again. [Try again] [Cancel] | I would make [Try again] to check for free space again, and if enough, start the download.
(In reply to comment #7) <snip> > Save-as is different case because it triggers a destination selection. The only > moment we can test for enough space is after the user accepts the selection, > this means we can act on low space when response_cb of the dialog is called. > > This creates the question: What do we tell the user? Do we present the > GtkFileChooserDialog again, plus a warning GtkInfoBar in the action-area? Do we > use a GtkInfoBar in the main browser window? > I think the new GtkFileChooserDialog with a GtkInfoBar is good enough for now. You don't have to hide the dialogue until you've fnished the check for space. Add a spinner inside the button that was just clicked, make the whole dialogue insensitive, and hide the dialogue when the check succeeds. If it doesn't info bar seems like the best option. There's also the case of downloads without a content-length, which could fill up the disk. A download failing while being downloaded should obviously be something ephy warns about.
Created attachment 230894 [details] [review] Preliminary patch. I am hitting some weird bug where the download is either *never* started or started without any notify:: signal (no progress, no status change). Attaching so perhaps someone else can see what I am doing wrong. I'll work on something else for a while, this is starting to get frustrating. == e-download: warn when filesystem is full When a new download starts, we check the free space of the destination filesystem, if it's less than the reported full size of the download we show a GtkInfoBar warning the user. We don't try to be smart warning on "5%" free space or something like that. Let's just tell users why their downloads don't finish (or won't).
Some further info on the problem: When things fail: * a download-requested callback does not set the location, the download never starts. * a download-requested callback on a file:/// uri produces no notify::progress nor notify::status, an empty file is created, data is never copied. What makes a difference: * using a policy-decision like WebKit's unit tests (make any loaded stuff be decision download), it works when using this trick.
Review of attachment 230894 [details] [review]: Removing from the unreviewed patches list, since the patch doesn't work :)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/epiphany/issues/99.