Package Details: xnviewmp-system-libs 0.95-1

Git Clone URL: https://aur.archlinux.org/xnviewmp-system-libs.git (read-only, click to copy)
Package Base: xnviewmp-system-libs
Description: An efficient multimedia viewer, browser and converter (using system libraries).
Upstream URL: http://www.xnview.com/en/xnviewmp/
Keywords: graphics
Licenses: custom
Conflicts: xnviewmp
Submitter: Corax
Maintainer: Corax
Last Packager: Corax
Votes: 16
Popularity: 0.91
First Submitted: 2017-01-21 15:31
Last Updated: 2020-02-04 23:01

Latest Comments

« First ‹ Previous 1 2 3 4 5 Next › Last »

Corax commented on 2019-01-31 23:06

@fuan_k: I'm confused, it's never stopped working for me, and for sure it still does! Deleting files in XnView results in them ending up in ~/.local/share/Trash/files/. Using strace, I do see that XnView tries to execve() gvfs-trash, which fails, and it then looks like it copies the file to Trash manually. Excerpt below (after filtering out some irrelevant operations):

[pid 23066] execve("gvfs-trash", ["gvfs-trash", "-h"], 0x7ffd56385268 /* 47 vars */) = -1 ENOENT (No such file or directory)
[pid 23066] exit_group(-1)              = ?
[pid 23066] +++ exited with 255 +++
[pid 23030] --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=23066, si_uid=1000, si_status=255, si_utime=0, si_stime=0} ---
[pid 23030] statx(AT_FDCWD, "/home/corax/.local/share/Trash/files/", AT_STATX_SYNC_AS_STAT, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFDIR|0700, stx_size=53248, ...}) = 0
[pid 23030] statx(AT_FDCWD, "/tmp/WD/PC290914_190131-225349.JPG", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_BASIC_STATS, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=7238748, ...}) = 0
[pid 23030] stat("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", 0x7ffd56382e50) = -1 ENOENT (No such file or directory)
[pid 23030] renameat2(AT_FDCWD, "/tmp/WD/PC290914_190131-225349.JPG", AT_FDCWD, "/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", RENAME_NOREPLACE) = -1 EXDEV (Invalid cross-device link)
[pid 23030] openat(AT_FDCWD, "/tmp/WD/PC290914_190131-225349.JPG", O_RDONLY|O_CLOEXEC) = 25
[pid 23030] statx(25, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_BASIC_STATS, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=7238748, ...}) = 0
[pid 23030] openat(AT_FDCWD, "/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", O_WRONLY|O_CREAT|O_TRUNC|O_CLOEXEC, 0666) = 26
[pid 23030] statx(26, "", AT_STATX_SYNC_AS_STAT|AT_EMPTY_PATH, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=0, ...}) = 0
[pid 23030] unlink("/tmp/WD/PC290914_190131-225349.JPG") = 0
[pid 23030] statx(AT_FDCWD, "/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", AT_STATX_SYNC_AS_STAT|AT_SYMLINK_NOFOLLOW, STATX_ALL, {stx_mask=STATX_ALL, stx_attributes=0, stx_mode=S_IFREG|0644, stx_size=7225344, ...}) = 0
[pid 23030] access("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", R_OK) = 0
[pid 23030] access("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", W_OK) = 0
[pid 23030] access("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", X_OK) = -1 EACCES (Permission denied)
[pid 23030] chmod("/home/corax/.local/share/Trash/files/PC290914_190131-225349_190131-230135.JPG", 0644) = 0

fuan_k commented on 2019-01-31 20:34

Note that I'm still having the issue and have to use the gvfs-trash script workaround in 0.93.

Creating such script in /home/user/bin/ works since apparently xnview looks for it there on its own.

Should we add this workaround to the PKGBUILD script until next version? Up to you. ;)

doskoi commented on 2019-01-11 05:18

Thanks, I solved it with the gvfs-trash script. I don't even need gvfs anymore :p

fuan_k commented on 2019-01-09 00:46

@doskoi look at this thread: https://newsgroup.xnview.com/viewtopic.php?t=37989

If this is the bug you encounter, it should be fixed in the next release. Otherwise, might want to report upstream.

Corax commented on 2019-01-08 21:47

@doskoi: no problem with moving files to the trash on my side. Does it work with the normal package (xnviewmp)?

doskoi commented on 2019-01-08 17:00

Deleted images are not moved to trash, even with gvfs installed and the option enabled in xnview settings.

Corax commented on 2018-09-23 23:46

No idea I'm afraid, is it up-to-date (0.36)?

Malstrond commented on 2018-09-23 10:13

Fix confirmed, removing qt5ct solves the problem. But why?

Corax commented on 2018-09-18 18:15

@ZZdrr: hmm, infinite recursion, not good... Looks like qt5ct is involved, does it work without it? There has to be something else though, because it works fine for me even with qt5ct. Maybe try with a blank XnView profile as well.

Malstrond commented on 2018-09-17 18:58

0.91 segfaults for me.

Strace:

--- SIGSEGV {si_signo=SIGSEGV, si_code=SEGV_MAPERR, si_addr=0x7ffe68719fe8} --- +++ killed by SIGSEGV (core dumped) +++

Journalctl:

Sep 17 20:52:14 desktop audit[9809]: ANOM_ABEND auid=1000 uid=1000 gid=1000 ses=1 pid=9809 comm="XnView" exe="/opt/xnviewmp/XnView" sig=11 res=1 Sep 17 20:52:14 desktop kernel: audit: type=1701 audit(1537210334.970:80): auid=1000 uid=1000 gid=1000 ses=1 pid=9809 comm="XnView" exe="/opt/xnviewmp/XnView" sig=11 res=1

gdb backtrace: https://www.dropbox.com/s/o8z8pvsfvrxb41m/xnview_gdb.txt