Package Details: xnviewmp-system-libs 1.8.3-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: https://www.xnview.com/en/xnviewmp/
Keywords: graphics
Licenses: custom
Conflicts: xnviewmp
Submitter: Corax
Maintainer: Corax
Last Packager: Corax
Votes: 26
Popularity: 0.027967
First Submitted: 2017-01-21 15:31 (UTC)
Last Updated: 2024-11-16 14:50 (UTC)

Latest Comments

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

Corax commented on 2019-02-02 12:14 (UTC)

Oh right, I understand now, that explains why Nemo was confused about the original location of the file! I have to admit that I'm not very clear on how the trash is supposed to work...

I have implemented your suggested workaround, putting the gvfs-trash wrapper in XnView's directory to avoid polluting the global PATH. That should do for now.

fuan_k commented on 2019-02-01 03:26 (UTC)

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 (UTC) (edited on 2019-01-31 23:08 (UTC) by Corax)

@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 (UTC)

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 (UTC)

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 (UTC)

@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 (UTC)

@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 (UTC)

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 (UTC)

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

Malstrond commented on 2018-09-23 10:13 (UTC)

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

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