Linux - move to trash

Reported bugs that have been closed and/or resolved

Moderators: XnTriq, xnview, Dreamer

Post Reply
pim
Posts: 27
Joined: Sun Nov 06, 2011 12:11 pm

Linux - move to trash

Post by pim » Sat Sep 29, 2018 6:30 pm

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.
Version 0.92 x64 (Sep 29 2018) - un*x

User avatar
xnview
Author of XnView
Posts: 31598
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Linux - move to trash

Post by xnview » Mon Oct 08, 2018 8:21 am

i use gvfs-trash
Pierre.

pim
Posts: 27
Joined: Sun Nov 06, 2011 12:11 pm

Re: Linux - move to trash

Post by pim » Sun Oct 14, 2018 4:25 pm

Well, gvfs-trash has been deprecated and is beeing replaced by:

Code: Select all

gio trash
However some conservative distros may still use the former command so it might be worth considering to use both commands in parallel at least for some time.

Thank you for support of Linux, Pierre and have a nice day.
Version 0.92 x64 (Sep 29 2018) - un*x

User avatar
pangwolin
Posts: 60
Joined: Sun Sep 25, 2016 7:53 pm

Re: Linux - move to trash

Post by pangwolin » Mon Nov 12, 2018 12:37 am

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. :)

User avatar
xnview
Author of XnView
Posts: 31598
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Linux - move to trash

Post by xnview » Tue Nov 13, 2018 12:21 pm

pangwolin wrote:
Mon Nov 12, 2018 12:37 am
Pierre, is there any plan to move to gio-trash eventually? Thanks, keep up the good work. :)
yes it will be fixed
Pierre.

pim
Posts: 27
Joined: Sun Nov 06, 2011 12:11 pm

Re: Linux - move to trash

Post by pim » Mon Dec 10, 2018 6:54 pm

Hi pangwolin.
If the gio trash works for you correctly, you can use alias in the meantime.

Code: Select all

alias gvfs-trash='gio trash'
Put it into your ~/.bashrc file.
Version 0.92 x64 (Sep 29 2018) - un*x

User avatar
pangwolin
Posts: 60
Joined: Sun Sep 25, 2016 7:53 pm

Re: Linux - move to trash

Post by pangwolin » Tue Dec 11, 2018 1:21 am

Thanks for the suggestion, I had thought about it, but it doesn't seem to work. Albeit I haven't tried restarting my xorg server, which is probably what is missing. Is it really working on your end?

Either way, I found another workaround for now which works just fine for me.

Code: Select all

sudo vim /usr/bin/gvfs-trash && sudo chmod +x /usr/bin/gvfs-trash
-------------------------------------------
#!/bin/sh
exec gio trash "${@}"
------------------------------------------

pim
Posts: 27
Joined: Sun Nov 06, 2011 12:11 pm

Re: Linux - move to trash

Post by pim » Tue Dec 11, 2018 5:40 pm

No need to restart xorg. Alias should work right away. Anyway you have another working solution so anybody with similar issue can try what suits him better.
Version 0.92 x64 (Sep 29 2018) - un*x

User avatar
xnview
Author of XnView
Posts: 31598
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Linux - move to trash

Post by xnview » Tue Dec 18, 2018 4:46 pm

:bugconfirmed: Thanks to your detailed description I can reproduce the problem.
Pierre.

User avatar
xnview
Author of XnView
Posts: 31598
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Linux - move to trash

Post by xnview » Thu Jan 31, 2019 1:50 pm

This problem is supposed to be fixed in XnView MP 0.93. Please check and confirm the bug fix here.
Pierre.

User avatar
pangwolin
Posts: 60
Joined: Sun Sep 25, 2016 7:53 pm

Re: Linux - move to trash

Post by pangwolin » Thu Jan 31, 2019 7:52 pm

The problem persists with 0.93.

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.

Code: Select all

pipe2([21, 23], O_CLOEXEC)              = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
pipe2([24, 25], O_CLOEXEC)              = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
pipe2([26, 27], O_CLOEXEC)              = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
pipe2([28, 29], O_CLOEXEC)              = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
getcwd("/home/user/test", 4096)      = 19
statx(AT_FDCWD, "/usr/local/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/home/user/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/local/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/home/user/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/local/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/home/user/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/local/sbin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/local/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/lib/jvm/default/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/site_perl/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/vendor_perl/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/core_perl/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/lib/jvm/default/bin/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/site_perl/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/vendor_perl/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/usr/bin/core_perl/gvfs-trash", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c34e0) = -1 ENOENT (No such file or directory)
rt_sigaction(SIGCHLD, {sa_handler=0x7f4259df7cc0, sa_mask=[], sa_flags=SA_RESTORER|SA_SIGINFO|SA_NOCLDSTOP, sa_restorer=0x7f4259bc13c0}, {sa_handler=SIG_DFL, sa_mask=[], sa_flags=0}, 8) = 0
rt_sigaction(SIGPIPE, {sa_handler=SIG_IGN, sa_mask=[], sa_flags=SA_RESTORER, sa_restorer=0x7f4259bc13c0}, NULL, 8) = 0
futex(0x7f425a0fdd84, FUTEX_WAKE_PRIVATE, 2147483647) = 0
pipe2([30, 31], O_CLOEXEC)              = 0
eventfd2(0, EFD_CLOEXEC)                = 32
clone(child_stack=NULL, flags=CLONE_CHILD_CLEARTID|CLONE_CHILD_SETTID|SIGCHLD, child_tidptr=0x7f4249120e10) = 5362
write(32, "*\0\0\0\0\0\0\0", 8)         = 8
close(32)                               = 0
close(29)                               = 0
close(21)                               = 0
fcntl(23, F_GETFL)                      = 0x1 (flags O_WRONLY)
fcntl(23, F_SETFL, O_WRONLY|O_NONBLOCK) = 0
close(25)                               = 0
fcntl(24, F_GETFL)                      = 0 (flags O_RDONLY)
fcntl(24, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
close(27)                               = 0
fcntl(26, F_GETFL)                      = 0 (flags O_RDONLY)
fcntl(26, F_SETFL, O_RDONLY|O_NONBLOCK) = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
ppoll([{fd=28, events=POLLIN}], 1, {tv_sec=30, tv_nsec=0}, NULL, 8) = 1 ([{fd=28, revents=POLLIN}], left {tv_sec=29, tv_nsec=999997558})
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
read(28, "\2\0\0\0execvp\0\0", 12)      = 12
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
close(28)                               = 0
read(30, 0x7ffe403c3640, 152)           = ? ERESTARTSYS (To be restarted if SA_RESTART is set)
--- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5362, si_uid=1000, si_status=255, si_utime=0, si_stime=1} ---
waitid(P_ALL, 0, {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=5362, si_uid=1000, si_status=255, si_utime=0, si_stime=0}, WNOHANG|WEXITED|WNOWAIT, NULL) = 0
wait4(5362, [{WIFEXITED(s) && WEXITSTATUS(s) == 255}], WNOHANG, {ru_utime={tv_sec=0, tv_usec=0}, ru_stime={tv_sec=0, tv_usec=7115}, ...}) = 5362
write(31, "\1\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 152) = 152
close(31)                               = 0
waitid(P_ALL, 0, 0x7ffe403c2f90, WNOHANG|WEXITED|WNOWAIT, NULL) = -1 ECHILD (No child processes)
rt_sigreturn({mask=[]})                 = -1 EINTR (Interrupted system call)
read(30, "\1\0\0\0\377\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0\0"..., 152) = 152
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
close(30)                               = 0
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
write(5, "\1\0\0\0\0\0\0\0", 8)         = 8
close(24)                               = 0
close(26)                               = 0
close(23)                               = 0
statx(AT_FDCWD, "/home/user/.local/share/Trash/files/", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c3760) = -1 ENOENT (No such file or directory)
statx(AT_FDCWD, "/home/user/.local/share/Trash/", AT_STATX_SYNC_AS_STAT, STATX_ALL, 0x7ffe403c3760) = -1 ENOENT (No such file or directory)
unlink("/sdc_data/deletion_test.png") = 0
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... ;-)

The latest comments from the Arch User Repository here are related to the issue: https://aur.archlinux.org/packages/xnviewmp-system-libs

User avatar
xnview
Author of XnView
Posts: 31598
Joined: Mon Oct 13, 2003 7:31 am
Location: France
Contact:

Re: Linux - move to trash

Post by xnview » Thu Mar 07, 2019 4:01 pm

This problem is supposed to be fixed in XnView MP 0.93.1. Please check and confirm the bug fix here.
Pierre.

User avatar
pangwolin
Posts: 60
Joined: Sun Sep 25, 2016 7:53 pm

Re: Linux - move to trash

Post by pangwolin » Sun Mar 10, 2019 5:44 pm

I can confirm this has been fixed in 0.93.1. Thank you!

Post Reply