MacFUSE crashing after NTFS-3G error

[GoogleCodeExporter]

What steps will reproduce the problem?
1. do a 'ditto /Volumes/macvolume/srcdir /Volumes/ntfs-3g-volume/destdir'
2. If in 'srcdir' are resource fork files, ntfs-3g can't handle them (see my 
post at ntfs-3g's site http://forum.ntfs-3g.org/viewtopic.php?p=3093)
3. ditto returns an error 'Operation not supported', later 'Bad file decriptor'

What is the expected output? What do you see instead?
The files are not copied. In /var/log/system.log the entry 'ReportCrash[18231]: 
Saved 
crashreport to 
/Library/Logs/CrashReporter/ntfs-3g_2008-02-21-135107_hostname.crash 
using uid: 0 gid: 0, euid: 0 egid: 0' is created.

What version of the product are you using? On what operating system?
It's MacFUSE 1.3.1 with NTFS-3G 1.2129 on Mac OS 10.5.2

Please provide any additional information below.
The crash report says the following:

---------------
Process:         ntfs-3g [18127]
Path:            /usr/local/bin/ntfs-3g
Identifier:      ntfs-3g
Version:         ??? (???)
Code Type:       X86 (Native)
Parent Process:  launchd [1]

Date/Time:       2008-02-21 13:51:07.351 +0100
OS Version:      Mac OS X 10.5.2 (9C31)
Report Version:  6

Exception Type:  EXC_CRASH (SIGABRT)
Exception Codes: 0x0000000000000000, 0x0000000000000000
Crashed Thread:  0

Application Specific Information:
*** single-threaded process forked ***

Thread 0 Crashed:
0   libSystem.B.dylib               0x96b2a0ea __kill + 10
1   libSystem.B.dylib               0x96ba13f2 raise + 26
2   libSystem.B.dylib               0x96bb09af abort + 73
3   libSystem.B.dylib               0x96ba2593 __assert_rtn + 101
4   libfuse.0.dylib                 0x00024e39 forget_node + 130
5   libfuse.0.dylib                 0x000262e9 fuse_lib_forget + 111
6   libfuse.0.dylib                 0x0002b9a6 do_forget + 40
7   libfuse.0.dylib                 0x0002ce6f fuse_ll_process + 685
8   libfuse.0.dylib                 0x0002e032 fuse_session_process + 38
9   libfuse.0.dylib                 0x0002aa62 fuse_session_loop + 181
10  libfuse.0.dylib                 0x00026bd6 fuse_loop + 28
11  ntfs-3g                         0x00008138 main + 471
12  ntfs-3g                         0x000025fa _start + 216
13  ntfs-3g                         0x00002521 start + 41

Thread 0 crashed with X86 Thread State (32-bit):
  eax: 0x00000000  ebx: 0x96bb096f  ecx: 0xbffffa4c  edx: 0x96b2a0ea
  edi: 0x00000000  esi: 0x00034f9c  ebp: 0xbffffa68  esp: 0xbffffa4c
   ss: 0x0000001f  efl: 0x00000286  eip: 0x96b2a0ea   cs: 0x00000007
   ds: 0x0000001f   es: 0x0000001f   fs: 0x00000000   gs: 0x00000037
  cr2: 0xffe176f0

Binary Images:
    0x1000 -     0x9fff +ntfs-3g ??? (???) /usr/local/bin/ntfs-3g
   0x24000 -    0x36fff +libfuse.0.dylib ??? (???) <0c1b542043f54bab71440b44cbc0cb37> 
/usr/local/lib/libfuse.0.dylib
   0x48000 -    0x75fff +libntfs-3g.21.dylib ??? (???) /usr/local/lib/libntfs-3g.21.dylib
0x8fe00000 - 0x8fe2da53  dyld 96.2 (???) <7af47d3b00b2268947563c7fa8c59a07> 
/usr/lib/dyld
0x905ff000 - 0x90731fef  com.apple.CoreFoundation 6.5.1 (476.10) 
<d5bed2688a5eea11a6dc3a3c5c17030e> 
/System/Library/Frameworks/CoreFoundation.framework/Versions/A/CoreFoundation
0x918db000 - 0x91938ffb  libstdc++.6.dylib ??? (???) 
<04b812dcec670daa8b7d2852ab14be60> /usr/lib/libstdc++.6.dylib
0x923aa000 - 0x923b1fe9  libgcc_s.1.dylib ??? (???) 
<f53c808e87d1184c0f9df63aef53ce0b> 
/usr/lib/libgcc_s.1.dylib
0x9356f000 - 0x9359afe7  libauto.dylib ??? (???) 
<42d8422dc23a18071869fdf7b5d8fab5> 
/usr/lib/libauto.dylib
0x93e7a000 - 0x93f59fff  libobjc.A.dylib ??? (???) 
<a53206274b6c2d42691f677863f379ae> 
/usr/lib/libobjc.A.dylib
0x9419c000 - 0x941a0fff  libmathCommon.A.dylib ??? (???) 
/usr/lib/system/libmathCommon.A.dylib
0x96873000 - 0x969abff7  libicucore.A.dylib ??? (???) 
<afcea652ff2ec36885b2c81c57d06d4c> 
/usr/lib/libicucore.A.dylib
0x96abb000 - 0x96c1aff3  libSystem.B.dylib ??? (???) 
<4899376234e55593b22fc370935f8cdf> 
/usr/lib/libSystem.B.dylib
0xfffe8000 - 0xfffebfff  libobjc.A.dylib ??? (???) /usr/lib/libobjc.A.dylib
0xffff0000 - 0xffff1780  libSystem.B.dylib ??? (???) /usr/lib/libSystem.B.dylib

------------------------

Original issue reported on code.google.com by stumpfs...@gmail.com on 21 Feb 2008 at 1:07

[GoogleCodeExporter]

I don't think you would be seeing "Operation not supported" -- you are likely 
seeing "Operation not supported on socket", 
isn't it? Well, you're seeing it because ntfs-3g is saying so:

/* ntfs-3g source */
ntfs_fuse_setxattr(...)
{
...
        if (ctx->streams != NF_STREAMS_INTERFACE_XATTR)
                return -EOPNOTSUPP;
...
}

On a side note, EOPNOTSUPP isn't the most appropriate error for ntfs-3g to 
return here. (EOPNOTSUPP is often mixed up 
with ENOTSUP.) EOPNOTSUPP is specifically for sockets. One exception is that of 
lchown(), where POSIX allows for 
EOPNOTSUPP even though you're not dealing with a socket.

All that said, your crash could be a valid issue. However, based on what you 
wrote, I cannot reproduce your problem. Can 
you double-check your instructions and/or be more precise on how to reproduce 
this?

Original comment by si...@gmail.com on 2 Mar 2008 at 11:35

[GoogleCodeExporter]

We didn't mix EOPNOTSUPP with ENOTSUP.

Linux has no ENOTSUP, it's a glibc alias to EOPNOTSUPP because Linus didn't 
accept
patches a decade ago which fixed this issue to conform to SuS. 

So, if it's an alias then why NTFS-3G uses EOPNOTSUPP instead of ENOTSUP? It's 
history.

NTFS-3G's code base is being developed on Linux for eight years. User space was
always a playground before the same code went into the kernel. But ENOTSUP is
"banned" in the kernel, just like typically those "confusing" macros which hide
portability/debugging/whatever details what some developers, who don't use those
code, don't like.

To keep the kernel driver and the user space code as close to each other as 
possible,
we decided to use EOPNOTSUPP because on Linux it's irrelevant and the kernel 
required
that one without redefinition of something else.

Then why isn't it renamed now? Because no guarantee that the driver won't move 
back
to the kernel. Actually the plan is just the opposite. Though I think the above
restiction was relaxed somewhat at some point in this decade.

The best way to fix this is to implement the ENOTSUP cases (there are only 25 
and I
don't think most needs more than several months of intensive work). 

This case probably could be workarounded by the streams_interface=xattr mount 
option.
Though its current implementation isn't the perfect one either because it won't 
allow
bigger than 64 kB extended attributes. XATTR and ADS handling also needs a 
rethought
and reimplementation.

Original comment by sz...@ntfs-3g.org on 4 Mar 2008 at 3:29

[GoogleCodeExporter]

Still can't reproduce your issue. 

Original comment by si...@gmail.com on 26 Mar 2008 at 8:46

• Changed state: WontFix