Package Details: xnviewmp-system-libs 0.99.1-1

Git Clone URL: (read-only, click to copy)
Package Base: xnviewmp-system-libs
Description: An efficient multimedia viewer, browser and converter (using system libraries).
Upstream URL:
Keywords: graphics
Licenses: custom
Conflicts: xnviewmp
Submitter: Corax
Maintainer: Corax
Last Packager: Corax
Votes: 19
Popularity: 0.035893
First Submitted: 2017-01-21 15:31
Last Updated: 2021-09-23 19:56

Latest Comments

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

fuan_k commented on 2019-02-01 03:26

The problem is that I don't (didn't) have the Trash directory in /home yet (until it got created by Thunar when I removed a test file from /home). So xnview fails to even create this Trash directory on its own, and when it doesn't find it, it unlinks the files instead.

Regardless, it shouldn't move files to the /home Trash when attempting to remove files from another partition for example. It should use the Trash from the same partition/file system.

I've already reported it upstream (see link to forum post below).

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

abouvier 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:

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)?

abouvier 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.