Temporary repos aren't always cleaned up

[mwleeds]

Linux distribution and version

Fedora 27

Flatpak version

0.11.3

Description of the problem

If an install or update operation is interrupted or fails, the temporary repos in /var/tmp/flatpak-cache-XXXXXX/ aren't necessarily cleaned up. This is separate from #1263 because I'm talking about the repo itself not the lock file.

Steps to reproduce

1. Run "flatpak install ..." to start an install
2. Once the install has gotten far enough to create a repo in /var/tmp/flatpak-cache-XXXXXX/, disconnect from the Internet to make the install fail.
3. Notice that the repo is never cleaned up.

If the operation fails because the flatpak process is killed, I suppose there's not much we can do. But if there's an error we should be able to clean up.

[alexlarsson]

Well, its kinda meant to work like that. This is how a partially downloaded result are picked up again when we restart the operation if you had some sort of transient failure. We should eventually remove it though, but I think that will happen on the next successful operation, no?

[uajain]

Right. I had the same experience to what Alex explained. This is a similar issue that I am right now looking into when the disk gets full. It just aborts and no cleanup is done. On one hand, that gives a chance for user to make more space available and re-try. That won't require to fetch the already present downloaded part.

On the other hand, I have been suggested to cleanup because in case of disk-space-full, there is no successful deployment of the app and the user will be left behind, with no disk space. Alex, do you have any ideas/suggestions on that?

[ramcq]

I think the recovery path from the full disk case should be more aggressive (like, drop all of the caches) because it's about disaster recovery and leaving the system usable again. Maybe we could remove all of the /other/ caches and on the first out of disk error, and if we have only one cache and we're still out of disk, then we have to remove it and throw the whole cache away?

Note that this out of disk fallback shouldn't be "plan A" - plan A should be avoiding getting into this state in the first place, because we're wasting either user disk space or bandwidth or both. But see ostreedev/ostree#1557 for that.

[mwleeds]

Looks like we already have #1119 about this