Should I mention again that I have this problem with Nautilus and
Thunar over Samba, with Xfce on sid, and there's not a trace of ZFS
anywhere in my network? It isn't just affecting ZFS.
--
Joe
On Tue, 15 Sep 2020 at 09:43:28 +0200, Holger Schröder wrote:
> I have found the reason for this. I had already set atime=off in my
> zpools some time ago. I tried to switch it on again (zfs set atime=on
> $pool). And the problem disappeared and everything works again.
Thanks, I can now reproduce
I have found the reason for this. I had already set atime=off in my
zpools some time ago. I tried to switch it on again (zfs set atime=on
$pool). And the problem disappeared and everything works again. But why
the newer glib can't handle it I don't know.
I hope this helps to find the error.
On Mon, 14 Sep 2020 at 09:09:34 +0100, Simon McVittie wrote:
> If you run it as `strace -efile nemo`, does the bug still happen? What
> output does it produce?
Ugh, I hadn't realised nemo is single-instance.
Please see whether you can reproduce this bug by installing libglib2.0-bin
and running
On Mon, 14 Sep 2020 12:16:05 +0200 =?UTF-8?Q?Holger_Schr=c3=b6der?=
wrote:
> Am 14.09.20 um 11:31 schrieb Simon McVittie:
> > Control: retitle -1 nemo: Can no longer copy files on zfs since
> > GLib 2.66.x Control: retitle 970263 glib2.0: nemo can no longer
> > copy files on zfs since 2.66.x
> >
Further info:
No problem copying the same file when logged into the host of the
shares, using mc (no GUI).
No problem copying the file via Samba from another workstation using
Unison.
Other people are not using Samba, so presumably the problem isn't with
Samba itself but the interface between
On Mon, 14 Sep 2020 at 09:09:34 +0100, Simon McVittie wrote:
> If you run it as `strace -efile nemo`, does the bug still happen? What
> output does it produce?
>From the strace log sent by private email due to containing personal
filenames etc., statx() is basically functional on the bug
I have tested Thunar from XFCE, same problem.
...
Am 14.09.20 um 11:31 schrieb Simon McVittie:
Control: retitle -1 nemo: Can no longer copy files on zfs since GLib 2.66.x
Control: retitle 970263 glib2.0: nemo can no longer copy files on zfs since
2.66.x
On Mon, 14 Sep 2020 at 11:19:04 +0200, Holger Schröder wrote:
I have zfs only.
zfs
Control: retitle -1 nemo: Can no longer copy files on zfs since GLib 2.66.x
Control: retitle 970263 glib2.0: nemo can no longer copy files on zfs since
2.66.x
On Mon, 14 Sep 2020 at 11:19:04 +0200, Holger Schröder wrote:
> I have zfs only.
zfs implemented how? The zfs-dkms kernel module, or
Am 14.09.20 um 10:09 schrieb Simon McVittie:
Control: tags -1 + moreinfo unreproducible
On Sun, 13 Sep 2020 at 11:26:46 +0200, Holger Schröder wrote:
Can no longer copy files with Nemo.
error when getting information for file descriptor numerical: result out of
range
What filesystem (ext4?
Control: tags -1 + moreinfo unreproducible
On Sun, 13 Sep 2020 at 11:26:46 +0200, Holger Schröder wrote:
> Can no longer copy files with Nemo.
>
> error when getting information for file descriptor numerical: result out of
> range
What filesystem (ext4? btrfs? FAT? NTFS? ...) are you copying
clone 970228 -1
reassign -1 libglib2.0-0
affects -1 nemo
thanks
On Sun, 13 Sep 2020, Holger Schröder wrote:
> I think this is related to the new glib (2.66.0-1) being in unstable.
> downgrade from testing (2.64.4-1) solves the problem.
Thanks for the info, cloning and reassigning accordingly.
I think this is related to the new glib (2.66.0-1) being in unstable.
downgrade from testing (2.64.4-1) solves the problem.
...
Package: nemo
Version: 4.6.5-1
Severity: normal
Can no longer copy files with Nemo.
error when getting information for file descriptor numerical: result out of
range
Cheers Holger...
-- System Information:
Debian Release: bullseye/sid
APT prefers unstable
APT policy: (500, 'unstable'),
15 matches
Mail list logo
