After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 158780 - Download manager does not notify when disk is full
Download manager does not notify when disk is full
Status: RESOLVED OBSOLETE
Product: epiphany
Classification: Core
Component: Downloads
unspecified
Other Linux
: Normal normal
: ---
Assigned To: Epiphany Maintainers
Marco Pesenti Gritti
Depends on:
Blocks: 755382
 
 
Reported: 2004-11-20 03:50 UTC by Adam Hooper
Modified: 2018-08-03 19:12 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
e-download: warn when filesystem is full (3.29 KB, patch)
2011-07-27 00:58 UTC, Diego Escalante Urrelo (not reading bugmail)
none Details | Review
Preliminary patch. (4.95 KB, patch)
2012-12-06 14:55 UTC, Diego Escalante Urrelo (not reading bugmail)
needs-work Details | Review

Description Adam Hooper 2004-11-20 03:50:57 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.
Comment 1 Reinout van Schouwen 2004-11-22 22:45:21 UTC
Somewhat related question: is it possible yet to plug an external downloader
into epiphany?
Comment 2 Christian Persch 2004-11-26 00:15:08 UTC
See also https://bugzilla.mozilla.org/show_bug.cgi?id=65770 .
Comment 3 Diego Escalante Urrelo (not reading bugmail) 2011-07-27 00:58:29 UTC
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
Comment 4 Akhil Laddha 2011-09-28 05:56:41 UTC
Was anybody able to review the patch ? Can patch be committed in master branch ?
Comment 5 Claudio Saavedra 2011-09-28 09:37:18 UTC
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.
Comment 6 Reinout van Schouwen 2011-09-30 23:21:25 UTC
(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.
Comment 7 Diego Escalante Urrelo (not reading bugmail) 2012-10-28 00:03:27 UTC
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.
Comment 8 Diego Escalante Urrelo (not reading bugmail) 2012-10-28 00:10:22 UTC
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.
Comment 9 Bastien Nocera 2012-10-28 09:38:32 UTC
(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.
Comment 10 Diego Escalante Urrelo (not reading bugmail) 2012-12-06 14:55:37 UTC
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).
Comment 11 Diego Escalante Urrelo (not reading bugmail) 2012-12-06 15:25:46 UTC
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.
Comment 12 Michael Catanzaro 2015-06-16 13:00:29 UTC
Review of attachment 230894 [details] [review]:

Removing from the unreviewed patches list, since the patch doesn't work :)
Comment 13 GNOME Infrastructure Team 2018-08-03 19:12:03 UTC
-- 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.