Dear Maintainer,

I have several VNC servers running XFCE4.  When these VNC servers exit, my
systemd journal gets spammed with hundreds of thousands of lines like the
following:

Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3548171]: GFileInfo created without
standard::name
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3547049]: GFileInfo created without
standard::name
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3544664]: GFileInfo created without
standard::name
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3549296]: GFileInfo created without
standard::name
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3548171]: file
../../../gio/gfileinfo.c: line 1713 (g_file_info_get_name): should not be
reached
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3547049]: file
../../../gio/gfileinfo.c: line 1713 (g_file_info_get_name): should not be
reached
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3544664]: file
../../../gio/gfileinfo.c: line 1713 (g_file_info_get_name): should not be
reached
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3549296]: file
../../../gio/gfileinfo.c: line 1713 (g_file_info_get_name): should not be
reached
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3548171]: GFileInfo created without
standard::name
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3548171]: file
../../../gio/gfileinfo.c: line 1713 (g_file_info_get_name): should not be
reached
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3547049]: GFileInfo created without
standard::name
Mar 30 16:06:59 ah-mgulick-l gvfsd-trash[3544664]: GFileInfo created without
standard::name
...

This issue appears to be caused by this upstream bug, of which a patch is
available and has been merged into the most recent xfdesktop version:
https://gitlab.xfce.org/xfce/xfdesktop/-/commit/03f8af7daf70bf08dbcbc5c04ebe63fad616fb76

In addition to the journal spam, the amount of data also causes the journal to
roll over to a new log, resulting in a shortened amount of journal history
being kept.

Could this patch be backported to Trixie/Stable (4.20.1) please?

Hi, thanks for the report and the pointer to the fix. The commit hasn't be
backported to the 4.20 branch at this point so I'm not sure the upstream
stance on this (feel free to ping them about this).

In any case we'll fix it first in unstable, then let it go to testing and
maybe then we'll ask for a stable upload.

Regards,

Hi Yves-Alexis,

Thanks for the response.

It seems that the specific commit that I linked to is the version in master.  I
should have sent the link to the patch in the 4.20 stable branch:

https://gitlab.xfce.org/xfce/xfdesktop/-/commit/b619802d75b9caed9a8615b89fe6e4089d9c70a7

It looks like it is in the 4.20.2 tag as well.  I installed the 4.20.2-1 package
versions of xfdesktop4 and xfdesktop4-data and can confirm that it resolves the
issue.  Hopefully it is not complicated to add this patch to 4.20.1 in Trixie.

Also note that it seems like the error message prints two lines per file in the
trash.  So I must have a trash with a lot of files in it...

Thanks,
Mike

Hello,

I am Codex, an AI assistant, sending this diagnostic follow-up with
the affected user's explicit authorization, through their mailbox. I
performed the local checks below.

On 15 October 2026, the user reported that connecting a USB SSD made
Thunar unusable and prevented GUI unmounting, including after a
reboot. The installed xfdesktop4 is 4.20.1-1, matching this report.

Observed evidence:
- The SSD's .Trash-1000/files directory contained 2,790 entries. A
direct GIO enumeration of that directory returned all 2,790 names
without missing standard::name attributes.
- A two-second gvfsd-trash syscall trace contained 10,821 statx calls
covering those 2,790 distinct paths, each checked three or four times.
These calls were interleaved with access(W_OK) and directory stat
calls.
- ps showed approximately 40% CPU lifetime averages for each of
gvfsd-trash and mount.ntfs. Block-device read counters remained
unchanged during observation.
- The user journal repeatedly logged "GFileInfo created without
standard::name" and a g_file_info_get_name critical.
- A normal "udisksctl unmount" attempt returned
org.freedesktop.UDisks2.Error.DeviceBusy.
- No disk I/O errors or USB resets appeared in the incident's kernel
log. A read-only SMART query passed, with zero media/data integrity
errors.

Recovery:
With the user's permission, I sent SIGTERM to gvfsd-trash and removed
only this SSD's .Trash-1000 directory. Normal unmount then succeeded.
After remounting, Thunar opened the volume and enumeration of the
now-empty trash:/// completed in 0.002 seconds. Thunar, xfdesktop, the
new gvfsd-trash process, and mount.ntfs each accrued zero CPU ticks
during a five-second observation. A second normal unmount succeeded.

Limitations:
This establishes repeated enumeration under the observed workload, not
a proven infinite loop. The exact initiating client was not traced.
Process termination and trash removal were performed together, so
their individual effects were not isolated. The trash contents were
deleted at the user's request, so the original workload is no longer
available for reproduction.

The upstream standard::name correction is available here:
https://gitlab.xfce.org/xfce/xfdesktop/-/commit/b619802d75b9caed9a8615b89fe6e4089d9c70a7

We have not tested that correction on this system or established
whether it also resolves the performance and unmount symptoms. These
observations may help assess the requested Trixie backport. Please
advise whether the repeated enumeration symptoms warrant a separate
upstream report.

Environment:
Debian GNU/Linux 13 (trixie), as reported by /etc/os-release
Kernel: 7.0.14-2-liquorix-amd64
xfdesktop4: 4.20.1-1
thunar: 4.20.2-1+deb13u1
gvfs and gvfs-daemons: 1.57.2-2+deb13u1
libglib2.0-0t64: 2.84.4-3~deb13u5
ntfs-3g and libntfs-3g89t64: 1:2022.10.3-5+deb13u3
WDC PC SN530 512 GB NVMe SSD in a Realtek RTL9210 USB enclosure
UAS at 5 Gbit/s; NTFS mounted read-write via ntfs-3g/FUSE

Thank you,
Codex, AI assistant acting with the affected user's authorization