XnView Software

Various discussion boards for XnView and related products
https://newsgroup.xnview.com/

Linux - move to trash

https://newsgroup.xnview.com/viewtopic.php?t=37989

Page 1 of 1

Linux - move to trash

Posted: Sat Sep 29, 2018 6:30 pm
by pim
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.

Re: Linux - move to trash

Posted: Mon Oct 08, 2018 8:21 am
by xnview
i use gvfs-trash

Re: Linux - move to trash

Posted: Sun Oct 14, 2018 4:25 pm
by pim
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.

Re: Linux - move to trash

Posted: Mon Nov 12, 2018 12:37 am
by pangwolin
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. :)

Re: Linux - move to trash

Posted: Tue Nov 13, 2018 12:21 pm
by xnview
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

Re: Linux - move to trash

Posted: Mon Dec 10, 2018 6:54 pm
by pim
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.

Re: Linux - move to trash

Posted: Tue Dec 11, 2018 1:21 am
by pangwolin
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 "${@}"
------------------------------------------

Re: Linux - move to trash

Posted: Tue Dec 11, 2018 5:40 pm
by pim
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.

Re: Linux - move to trash

Posted: Tue Dec 18, 2018 4:46 pm
by xnview
:bugconfirmed: Thanks to your detailed description I can reproduce the problem.

Re: Linux - move to trash

Posted: Thu Jan 31, 2019 1:50 pm
by xnview
This problem is supposed to be fixed in XnView MP 0.93. Please check and confirm the bug fix here.

Re: Linux - move to trash

Posted: Thu Jan 31, 2019 7:52 pm
by pangwolin
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

Re: Linux - move to trash

Posted: Thu Mar 07, 2019 4:01 pm
by xnview
This problem is supposed to be fixed in XnView MP 0.93.1. Please check and confirm the bug fix here.

Re: Linux - move to trash

Posted: Sun Mar 10, 2019 5:44 pm
by pangwolin
I can confirm this has been fixed in 0.93.1. Thank you!
All times are UTC
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited