maybe I should have posted this to ntf3g project...

OK, another problem, I can't create files bigger than 4GB on the NTFS partition. I
think that has to do sth with fuse/ntfs-3g implementation on macosx rather than with
ntfs-3g driver itself. Maybe of use would be to mention that if I delete ntfs.fs
(i.e. the original one from apple) then ntfs-3g doesn't work. Is there any dependency
(which also causes the 4GB limit)?

Yes, please don't report issues here that are clearly unrelated to MacFUSE.

As for the 4GB thing, some relevant things were changed in the newest release (MacFUSE Core 0.1.7). Please 
upgrade and see if the > 4GB stuff works fine.

OK, installed Core 0.1.7 and NTFS-3G 20070116-r4.dmg (sudo rm'ed all files installed
before and deleted receipts).

I could create an 8 GB sparse image (which I couldn't before). Also tried to create a
7 GB toast image (from a DVD) - it tries to allocate space first and splits into
parts (toast problem?).
Then tried to create a 4.37 GB DVD-R .dmg image (full size read-write). It took
insane amount of time, activity monitor showed constant 11.5 MB write speed and 18.5
GB (!!!) written in total when finished. Nevertheless the file is bigger than 4GB and
it is there.

I'm still getting the 0 KB size/free space thing.

Creating a new folder/file in other application than finder (or vice versa) doesn't
refresh the filesystem. I have to log out/in to see it or quit/relaunch the
application in question for it to see the changes. 

Sorry for reporting things which are/could be more related to ntfs-3g rather than to
the macfuse project itself - the thing is I don't have much knowledge about all this
and I assume that people don't have these problems on linux (i.e. that they are
macosx specific). So I'm just reporting problems which I noticed. Please understand
that my interest (as well as interest of many others) is focused onto the so much
needed ntfs write capability.

Note: i didn't compile anything myself (don't know how to nor have the tools), I
assume that NTFS-3G 20070116-r4.dmg is compatible with 0.1.7 (i.e. doesn't need
recompile).

MacFUSE Core 0.1.7 fixes the 0 KB size/free space issue by actively waiting for the file system to initialize before 
calling it "done". If the caller (ntfs-3g in this case) is using the ping_diskarb option, then the caller doesn't have 
to do anything, as MacFUSE will let Disk Arbitration know at the right time. If, however, the caller is *not* using 
ping_diskarb (which I think is the case with ntfs-3g here), then the caller has to wait itself before proceeding. 
0.1.7 adds a system-wide notification that's sent to the distributed notification center in Mac OS X when the 
mount is truly complete. The caller should be an observer for this notification and wait. The reason you're still 
seeing the 0 KB thing is because Disk Arbitration is likely being pinged too early still.

Though the problems described here aren't necessarily the fault of MacFUSE or NTFS-3G, one solution lies in 
fusefs.kext.

The SIGTERM problem extends from the fact that ntfs-3g userspace daemon does not respond to SIGTERM 
when OS X tries to shut down.  While other daemons might, NTFS-3G doesn't.  What's being revealed here is a 
layering violation of sorts.  NTFS-3G volumes are mounted in userspace, but refuse to die like a userspace 
program.  Thus, to eliminate the error, FUSE filesystems should be unmounted when the shutdown procedure 
initiates.

There are two ways to do this.  One is by creating an NTFS-3G StartupItem that only responds to the "stop" 
request, and subsequently unmounts NTFS-3G filesystems.  Alternatively, and likely more efficient, is having 
fusefs.kext register for shutdown notifications from IOKit, so that *all* FUSE filesystems can be unmounted 
prior to shutdown.

Would it be possible to add unmount-on-shutdown (or restart) support to fusefs.kext to avoid seeing errors 
like this in other FUSE filesystems?

Hopefully with the notifications in place, this can be handled on the ntfs-3g side.