cancel a download if space is very tight

[tomeu]

From (#172): For example stop before there's only 1MB free.

[erikos]

The problem I see here, is that we would need some sort of notification that the download has been stopped - or been canceled due to space constraints. And as we are in string freeze...

[erikos]

I think this needs proper handling with a dialog (string based).

[timClicks]

Would it be possible to alter Browse's behaviour before making a download? This could be achieved through an HTTP HEAD request, then checking for available space.

[bernie]

This bug occurs often in the field. Children download huge files, often in parallel, without thinking of the consequences. It's a very good way to screw up your datastore and make your system unbootable.

Thus, rising priority.

[bernie]

Replying to timClicks:

Would it be possible to alter Browse's behaviour before making a download? This could be achieved through an HTTP HEAD request, then checking for available space.

Nope, because users download several things in parallel so space runs out in unpredictable ways. We should figure out a way to interrupt downloads before the filesystem becomes full.

[humitos]

I tested it in build 18 and it is still happening.

I think this bug is important because it makes Sugar to not work anymore. I mean, there is no way to remove the file because a dialogue with the message "The Journal is full" with the button "Show Journal" is popped up all the time and it doesn't allow us to do anything.

I had to login with Ctrl + Alt + F2 and remove a video that I was downloading to make Sugar to work again.

How we should implement this? Should we check the free space on every "chunk" downloaded by Browse?

[humitos]

Some discussion here:

​http://lists.sugarlabs.org/archive/sugar-devel/2012-September/039516.html

[humitos]

v2 - improved

[greenfeld]

I am concerned that 50 MB might be too much space to save. A 2 GB XO-1.5 with an unedited OLPC build will only have about 170 MB free to start with.

A bootable Fedora SoaS USB with an overlay partition also might have limited space available.

Refusing to download with ~30% provided space available seems like a bit much in this case. Perhaps 10 MB or 20 MB would be better.

But then this might just be bikesheding and not relevant except to the few XO deployments that actually purchased 2 GB units.

[humitos]

Example

[humitos]

This patch needs a patched version of sugar that implements "enough_space" method in Activity class

[humitos]

enough_space method on Activity class

[humitos]

error (LOW_SPACE) signal in datastore

[humitos]

Simon, I've just uploaded the sugar-toolkit-gtk3 patches related to this one.

[humitos]

This patch puts the "enough_space" in the Download class inside the Browse Activity, so we don't have to modify sugar3.activity.Activity class in this cycle

[manuq]

Finally pushed f96848a9 . Thanks Manuel.

[greenfeld]

The patch seems to work in Browse-148, but has an order of operations issue in the error dialog.

The section

free_space_mb = self._free_available_space( 
    path=self.temp_path) - SPACE_THRESHOLD \ 
    / 1024.0 ** 2 

likely should read

free_space_mb = (self._free_available_space( 
    path=self.temp_path) - SPACE_THRESHOLD) \ 
    / 1024.0 ** 2 

[godiard]

Humitos, manuq, can you see at the last comment from Sam?

A comment in _free_available_space explaining what unit is used (apparently return bytes) should be good. Also enough_space method say the size parameter should be in kb,
but is not consistent with the use of _free_available_space inside it.

[humitos]

I attached a new patch to fix what Sam mentioned in the previous comment and this patch adds as well some comments about the units used in the code.

[manuq]

Good catch. Pushed humitos patch as f40101a4 .

[dnarvaez]

Milestone 0.98 deleted