nemo-file: fall back to custom-icon-name when the custom-icon path no longer exists

[nynjapirate]

A custom icon set by path silently wins over a valid custom icon name, even when the path points at a file that no longer exists — so the item ends up with no custom icon at all, with no error and no fallback.

Cause

In get_custom_icon() (libnemo-private/nemo-file.c):

custom_icon_uri = get_custom_icon_metadata_uri (file);

if (custom_icon_uri) {
        icon_file = g_file_new_for_uri (custom_icon_uri);
        icon = g_file_icon_new (icon_file);   /* succeeds even if the file is GONE */
        ...
}

if (icon == NULL) {                            /* so this is never reached */
        custom_icon_name = get_custom_icon_metadata_name (file);
        ...
}

g_file_icon_new() does not touch the filesystem, so it happily returns a valid GFileIcon for a path that no longer resolves. That GIcon is non-NULL, so the custom-icon-name branch below is never taken. The GFileIcon then fails to load at draw time and the item simply shows no custom icon.

Preferring the path over the name is intentional and unchanged here — the bug is that a dead path still wins.

Impact

Reorganising an icon collection (moving/renaming the image files) silently blanks the custom icon of every file and folder that referenced them. There is no error, no warning, and no fallback — including for items that also have a perfectly good custom-icon-name stored, which is simply never consulted.

I hit this with 26 folders whose icons went blank after the icon files were moved. Several of them had a valid custom-icon-name in their metadata the entire time; it was never used.

Fix

Skip a custom-icon path that no longer resolves, so the existing custom-icon-name fallback is reached. Existence is checked for native files only, so no blocking I/O is introduced for remote locations.

Reproducing

gio set -t string  DIR metadata::custom-icon-name  folder-music          # valid theme icon
gio set -t string  DIR metadata::custom-icon       file:///does/not/exist.png

• Before: DIR shows no custom icon — the valid custom-icon-name is ignored.
• After: DIR shows folder-music.

Verified against the two code paths with identical metadata: the old logic builds a GFileIcon that renders nothing; the new logic skips the dead path and resolves the themed icon.

[mtwebster]

Hi, unfortunately this won't work -

g_file_is_native() cannot tell if a location is actually local filesystem or a local mount of a remote filesystem.

Also, you wouldn't ordinarily have both a path and an icon-name set. Using nemo's file properties window clears whichever path you didn't use, so you'd never have both to choose from.

It looks like our 'folder-color' extension may potentially allow both values to be set, but that should be fixed there.