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 721726 - Partial file left on disk when download is canceled
Partial file left on disk when download is canceled
Status: RESOLVED NOTGNOME
Product: epiphany
Classification: Core
Component: Downloads
3.10.x (obsolete)
Other Linux
: Normal minor
: ---
Assigned To: Epiphany Maintainers
Epiphany Maintainers
polish
Depends on:
Blocks:
 
 
Reported: 2014-01-07 20:34 UTC by Michael Catanzaro
Modified: 2014-01-09 10:42 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Michael Catanzaro 2014-01-07 20:34:37 UTC
* Start downloading a big file.
* Try to close Epiphany. When presented with a warning dialog to indicate that your active download will be canceled, click close anyway.

The partially-downloaded file is left on disk. Since the file is unusable and this could confuse the user, I would expect it to be removed.
Comment 1 William Jon McCann 2014-01-07 21:23:14 UTC
I think it probably shouldn't write to the final destination directly anyway.

I prefer the way other browsers create a "lock" file in the final location, download to a "partial" file, and only move the download into the final location when it is completed.
Comment 2 Carlos Garcia Campos 2014-01-08 12:01:19 UTC
(In reply to comment #1)
> I think it probably shouldn't write to the final destination directly anyway.
> 
> I prefer the way other browsers create a "lock" file in the final location,
> download to a "partial" file, and only move the download into the final
> location when it is completed.

This should probably be done by WebKit.
Comment 3 Carlos Garcia Campos 2014-01-08 13:43:26 UTC
(In reply to comment #2)
> (In reply to comment #1)
> > I think it probably shouldn't write to the final destination directly anyway.
> > 
> > I prefer the way other browsers create a "lock" file in the final location,
> > download to a "partial" file, and only move the download into the final
> > location when it is completed.
> 
> This should probably be done by WebKit.

Actually, webkit already does that, it uses g_file_replace() for exactly that reason, see g_file_replace docs:

"This will try to replace the file in the safest way possible so that any errors during the writing will not affect an already existing copy of the file. For instance, for local files it may write to a temporary file and then atomically rename over the destination when the stream is closed."
Comment 4 Carlos Garcia Campos 2014-01-09 10:42:47 UTC
Ok, I've fixed this in webkit in the end, see https://bugs.webkit.org/show_bug.cgi?id=126686