[krita/video-export-rebased] libs/ui: Save to a temporary file, then copy the result over on success (fwd)

[Jonathan Olsson]

Agreed, though not a developer here, don't delete my file from disk before
a new one is saved. I prefer a message that tells me I'm out if disk space
so I can clean up or select another location.

/Jonathan



Den 16 aug. 2016 18:12 skrev "Boudewijn Rempt" <boud at valdyas.org>:

> On Tue, 16 Aug 2016, Dmitry Kazakov wrote:
>
> > Can we somehow limit this behavior to network files only?
>
> I would prefer not to. This also solves the issue we've seen where a
> failure to save breaks the original file. In fact, this is how saving
> should have been implemented already, and as I thought it had been
> implemented.
>
> You never directly overwrite an existing file, you always save to a
> temporary file and then let the OS do the copy. Anything else is a bug.
>
> > There are two problems I see:
> >
> > 1) If some other application, like Blender, is waiting on Krita-edited
> file
> > with inotify (QFileSystemWatcher), it may go crazy when we rename and
> > delete the file. The inotify opject will be destroyed after that.
>
> Did you test that, or is this just a hunch?
>
> > 2) What if the user works with 700MiB image? It mean he needs twice the
> > size of the image free space just to be able to save it. Many people will
> > be unhappy with it.
>
> But far fewer people than are currently unhappy because our unsafe saving
> code breaks their files. And if the file hasn't been saved before there is
> no extra disk space needed,
>
> > 3) What if there is not enough free space in Temp folder? The user will
> > never be able to save the image? That is a dataloss bug.
>
> Then they get an error message and can clean out their temp folder.
>
> But they WILL NOT LOSE THEIR ORIGINAL FILE. And that is what counts.
>
> And as I said, this is how saving was supposed to happen anyway.
> --
> Boudewijn Rempt | http://www.krita.org, http://www.valdyas.org
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kimageshop/attachments/20160816/37424e1e/attachment.html>