1590061 - Use gio to remove temporary files

Status: NEW

(Toolkit :: Downloads API, enhancement, P5)

Description

[Hussam Al-Tayeb]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

On Linux, temporary files are downloaded on my computer to /tmp/mozilla_hussam0/ and added to the gvfs-metadata database along with the download url. This is the correct behavior.
However, old downloads not in the download history or on disk anymore remain in the gvfs-metadata database.

Expected results:

The way to fix this is to remove them from the database on removal from the download manager history. The importance of this is that if they are saved in /tmp/, they are eventually purged by the system. However, they do remain in the gvfs-metadata history and polluting it.
While this is not a major issue in itself, at the very least clean up the gvfs-metadata database when I manually remove entries from the download history.

Comment 1

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

This would probably require DownloadPlatform to introduce a new method, to be invoked at the right time, though I'm not 100% sure what that time would be.
From what I understand, we annotate each downloaded file with metadata about where it came from, Webkit does the same.
This metadata is used by the system and can be useful to the user, for various reasons.

The problem is how to decide when that metadata should be removed. Removing a download from the Firefox UI doesn't necessarily mean the user doesn't care anymore about the target file metadata, maybe the user just likes to work with clean lists (I tend to do this on some software, I'm sure others have the same habit). This would end up being a dataloss for many.

Removing it for downloads that are no more on disk seems more acceptable as a solution. We have a point where we actually check if a file shown in the UI still exists on disk, and that may be the right hook point. But shouldn't the system itself taking care of removing metadata for no-more existing files?
Even if we implement it on our side, we'll miss anything that was already removed from the Firefox UI and then removed from the disk, later.
At that point you'd still need a cron job to cleanup leftovers, thus our Firefox fix wouldn't be of great help in general.

This is more complex to handle than bug 1535950, thus I'm marking as a P5 because it doesn't look immediately actionable, ideas and patches are welcome.

Comment 2

[Hussam Al-Tayeb]

(In reply to Marco Bonardo [:mak] from comment #1)

But shouldn't the system itself taking care of removing metadata for no-more existing files?

First of all, thank you for taking a look at this bug report. I have asked gvfs/glib developers about this a few years ago. They said that they don't automatically clean the metadata database under the assumption that files may "come back" in the future.

Others have suggested to clean up based on aging.

• https://gitlab.gnome.org/GNOME/gvfs/issues/117 (Note the last two comments).

Comment 3

[Marco Bonardo [:mak] (Away Apr 25 - May 5)]

(In reply to Hussam Al-Tayeb from comment #2)

They said that they don't automatically clean the metadata database under the assumption that files may "come back" in the future.

They can surely make better informed decisions than me regarding their software.

Others have suggested to clean up based on aging.

• https://gitlab.gnome.org/GNOME/gvfs/issues/117 (Note the last two comments).

I see. I found various discussions about this on the Web, and it's unclear what's the best path forward here. Unfortunately, as I said, it doesn't look like completely solvable on the app side, not for Firefox at least.
The custom cron job for now still looks like the best solution...

Comment 4

[Hussam Al-Tayeb]

I am doing just that. A cron job @reboot to remove /home/hussam/.local/share/gvfs-metadata/root-*