Re: [fuse-devel] Bug report: ntfs3g process dies frequently with fuse 2.9.1

[Christoph L. <la...@we...>]

2012-10-19 13:50 Jean-Pierre André:
> In most situation, the initial clue is logged into the
> system log (whose location depends on the distribution),

OK, thanks for your hints – I inspected my system log (which is created 
by syslog-ng without any custom configuration) and couldn't find any 
related information.  I inspected /var/log/messages; on my system there 
is no log file that would contain further information more specific to fuse.

> and ntfs-3g and fuse try to log unusual conditions which
> are met.

So all that I found about fuse is the startup message "fuse init (API 
version ...)" (with version either 7.18 or 7.20).

> The fix I suggested is related to having
> "fuse internal error: node NNN not found" in the system
> log file. Do you have this or something else logged ?

No, I don't – so it is probably a different bug that I experienced.

There was also some log output from the ntfs-3g process, which, AFAICT, 
was logged whenever I tried to umount the partition after the ntfs-3g 
process had died:

Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Version 2012.1.15 external 
FUSE 29
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Mounted /dev/sda4 
(Read-Write, label "Data (Windows/Linux)", NTFS 3.1)
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Cmdline options: 
rw,uid=1000,gid=100,windows_names
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Mount options: 
rw,allow_other,nonempty,relatime,fsname=/dev/sda4,blkdev,blksize=4096
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: User mapping built, Posix 
ACLs in use, configuration type 7
Oct 16 23:04:55 CLANGE-x220t ntfs-3g[4321]: Unmounting /dev/sda4 (Data 
(Windows/Linux))

I didn't see any further ntfs-3g output.

>> With regard to this I have reported the problem back to Gentoo, my
>> Linux distributor (where fuse-2.9.1-r1 is the latest version so far);
>> see https://bugs.gentoo.org/show_bug.cgi?id=437568#c11
>
> The "-r1" suffix may mean some fix has been applied to
> the base fuse-2.9.1, so I cannot really tell whether the one
> I mentioned has been applied. Get the corresponding
> source code, and check.

In this case it probably doesn't mean that any patch has been applied. 
The following diff between 2.9.1 and 2.9.1-r1 shows some minor changes, 
IIUC related to distribution-specific tools and path lookups:

--- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< ---
$ diff /usr/portage/sys-fs/fuse/fuse-2.9.1{,-r1}.ebuild
3c3
< # $Header: /var/cvsroot/gentoo-x86/sys-fs/fuse/fuse-2.9.1.ebuild,v 1.1 
2012/08/01 22:31:55 radhermit Exp $
---
> # $Header: /var/cvsroot/gentoo-x86/sys-fs/fuse/fuse-2.9.1-r1.ebuild,v 1.5 2012/10/17 03:41:17 phajdan.jr Exp $
6c6
< inherit libtool linux-info
---
> inherit eutils libtool linux-info toolchain-funcs
15c15
< KEYWORDS="~alpha ~amd64 ~arm ~hppa ~ia64 ~ppc ~ppc64 ~sparc ~x86 
~x86-fbsd ~amd64-linux ~x86-linux"
---
> KEYWORDS="~alpha amd64 ~arm ~hppa ~ia64 ppc ppc64 ~sparc x86 ~x86-fbsd ~amd64-linux ~x86-linux"
18a19,20
> RDEPEND=""
> DEPEND="virtual/pkgconfig"
37a40,42
>       local UDEV_PATH=/lib/udev
>       has_version sys-fs/udev && UDEV_PATH="$($(tc-getPKG_CONFIG) --variable=udevdir udev)"
>
41c46
<               UDEV_RULES_PATH="${EPREFIX}/lib/udev/rules.d" \
---
>               UDEV_RULES_PATH="${EPREFIX}/${UDEV_PATH}/rules.d" \
65c70
<       find "${ED}" -name "*.la" -delete
---
>       prune_libtool_files
--- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< --- %< ---

In particular, the source URL is the same, and no patches are applied.

Cheers,

Christoph

-- 
Christoph Lange, http://www.facebook.com/ch.lange, Skype duke4701