Hello there.
What command is used in XnViewMP to move files to trash under Linux?
I'm asking because after fresh install the trash in XnView stopped working for me. Terminal output has shown nothing noticable.

Hello, I have the same issue here. My system doesn't have gvfs-trash anymore, only gio-trash.

Files are moved to trash correctly, but they have the date of deletion appended to the base name, before their extension, and moved to trash afterwards.

I had noticed an issue in 0.90 recently, where files where not moved to trash at all, instead some strange 0 byte files were created in the trash. The deletion confirmation dialog box didn't seem to work, and the original file was still in its original path.

After updating to 0.92, the files are moved to trash properly, but the original path is not properly saved, and this strange date is appended to the file name as I said earlier.

Pierre, is there any plan to move to gio-trash eventually? Thanks, keep up the good work.

I have both glib2 (for gio) and gvfs (for gvfsd) packages installed on Arch Linux.

Files are unlinked directly instead of moved to trash, even though the option to use "recycle bin" is active in settings.

Below is an strace showing that xnview is looking for gvfs-trash when trying to delete a file that is located on another hard drive. Note that regardless if the current working directory (the first "getcwd()" syscall) is /home or any other mount point, the result will be the same. Xnview might be calling other processes that I can't see here? Either way, it should instead look for the trash directory relative to the current file being deleted, not always the same Trash path in /home. That's what gio trash does for us I assume. Not familiar with how that would work with other distributions if they still use gvfs-trash though, that's the problem.

Xnview desperately looks for gvfs-trash in some hard coded (?) paths but doesn't find any because it doesn't exist anywhere. Then, as a fall back, it is looking for a Trash path in /home/user, namely ~/.local/share/Trash but it doesn't exist (it happens!). I have a separate Trash directory for each hard drive / mount point / file system (and currently none on my /home partition). Since it doesn't find the Trash there, it just unlinks the file directly (xnview doesn't even attempt to create it itself).

Creating a script as /home/user/bin/gvfs-trash as a workaround still works.

Maybe xnview should be programmed to look for the gio binary (in /usr/bin/gio or /usr/lib/gio) and if it doesn't find it, fall back to looking for the gvfs-trash binary for Linux distributions who still use that and do the rest of the logic in case none were found. But in that case, the logic should be improved if possible, as there can be multiple trashes around...