From owner-freebsd-ports@FreeBSD.ORG Mon Jul 17 05:45:25 2006 Return-Path: X-Original-To: freebsd-ports@freebsd.org Delivered-To: freebsd-ports@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 962FA16A4E0 for ; Mon, 17 Jul 2006 05:45:25 +0000 (UTC) (envelope-from freebsd-ports@m.gmane.org) Received: from ciao.gmane.org (main.gmane.org [80.91.229.2]) by mx1.FreeBSD.org (Postfix) with ESMTP id DBA3E43D49 for ; Mon, 17 Jul 2006 05:45:24 +0000 (GMT) (envelope-from freebsd-ports@m.gmane.org) Received: from list by ciao.gmane.org with local (Exim 4.43) id 1G2Luu-00066J-Ay for freebsd-ports@freebsd.org; Mon, 17 Jul 2006 07:45:16 +0200 Received: from www.creo.hu ([217.113.62.14]) by main.gmane.org with esmtp (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Jul 2006 07:45:16 +0200 Received: from csaba-ml by www.creo.hu with local (Gmexim 0.1 (Debian)) id 1AlnuQ-0007hv-00 for ; Mon, 17 Jul 2006 07:45:16 +0200 X-Injected-Via-Gmane: http://gmane.org/ To: freebsd-ports@freebsd.org From: Csaba Henk Date: Mon, 17 Jul 2006 05:45:07 +0000 (UTC) Lines: 61 Message-ID: References: <20060715195146.GE1106@roadrunner.aventurien.local> X-Complaints-To: usenet@sea.gmane.org X-Gmane-NNTP-Posting-Host: www.creo.hu User-Agent: slrn/0.9.8.1 (FreeBSD) Sender: news Subject: Re: Port of FUSE-NTFS to FreeBSD (sort of) X-BeenThere: freebsd-ports@freebsd.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: Porting software to FreeBSD List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 17 Jul 2006 05:45:25 -0000 On 2006-07-15, Ulrich Spoerlein wrote: > the FUSE NTFS team has release a new version of its NTFS driver which > promises to deliver write support for NTFS to FreeBSD. > http://sourceforge.net/mailarchive/forum.php?thread_id=3D23836054&forum_id= >=3D2697 > > I made a port of the driver and fixed some build errors, but the port is > still not working (for me), as it is running into an infinite loop. > > If some people would like to take it from here, I'd be glad to hand the > port over, as I don't have that much time. At least all the boring stuff > (pkg-descr, pkg-plist) has been taken care of. > > Here's further debugging info: > > Mounting the fuse device will result in an infinite loop in > ntfs_attr_pread calling ntfs_pread unsuccessfully over and over again: > > (gdb) bt > #0 ntfs_attr_pread (na=3D0x805e100, pos=3D476846, count=3D3354, b=3D0x8083= > 000) at attrib.c:887 > #1 0x080497f3 in ntfs_fuse_get_nr_free_clusters (vol=3D0x8054100) at ntfs-= > 3g.c:200 > #2 0x080498f1 in ntfs_fuse_statfs (path=3D0x480b62db "/", sfs=3D0xbfbfe600= > ) at ntfs-3g.c:254 > #3 0x480b1cb1 in fuse_statfs () from /usr/local/lib/libfuse.so.2 My bet is that it's not a FUSE issue (neither kernel, nor lib). The bug is apparently triggered below the fuselib level. I think it's either some platform-related subtlety or a plain bug in the ntfs-3g code. I also made a try with ntfs-3g, but, as I don't have real ntfs partitions, I only tried with a quickly "mkntfs -fF"-d file. With that, it works fine. So, the misbehaviour is not easy to reproduce by our current knowledge, that is, no other interested party can continue the work from where you are. I suggest you to go over one (or more) of the following possibilities: - Make a try with several ntfs volumes. If it works with most of them, send a pr for adding the port, and user feedback can help in tracking down the bug. (Btw, I'd suggest fusefs-ntfs3g or fusefs-ntfs-3g or fusefs-ntfs_3g as the port name -- I think including "3g" is necessary to make it unambigous what's we are dealing with.) - Try to mount the same ntfs volume from Linux (if you don't have Linux on your box, you can still do it with a livecd). If the same thing happens, it's a bug in ntfs-3g, and you can report upstream (although the author is on a vacation ATM, as you probably know). - If gdb fails to uncover the reasons, fail back to plain old printf debug. Use the "-odebug,no_detach" mount options. Then the fs daemon won't go background and won't swallow output, so if you insert printfs you can make use of them. Moreover, the daemon will produce a lot of debug output without needing to touch the code. Regards, Csaba