ntfs-3g doesn't respond to SIGTERM

[GoogleCodeExporter]

What steps will reproduce the problem?
reboot

What is the expected output? What do you see instead?
expected nothing, instead i see "ntfs-3g doesn't respond to SIGTERM" upon 
reboot/shutdown, causes a 10 - 15 secs lag.

What version of the product are you using? On what operating system?
MacFUSE 0.1.0_beta6-r3.dmg and NTFS-3G 20070116-r4.dmg from 
http://forum.insanelymac.com/index.php?showtopic=38920&hl=macfuse

Please provide any additional information below.
also my spotlight behaves badly / doesn't work / doesn't add new files 
into index. Don't know anything more specific.

Original issue reported on code.google.com by jarod...@gmail.com on 21 Jan 2007 at 1:53

[GoogleCodeExporter]

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

Original comment by jarod...@gmail.com on 21 Jan 2007 at 1:54

[GoogleCodeExporter]

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)?

Original comment by jarod...@gmail.com on 21 Jan 2007 at 3:17

[GoogleCodeExporter]

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.

Original comment by si...@gmail.com on 23 Jan 2007 at 5:41

[GoogleCodeExporter]

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).

Original comment by jarod...@gmail.com on 23 Jan 2007 at 9:51

[GoogleCodeExporter]

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.

Original comment by si...@gmail.com on 23 Jan 2007 at 4:25

[GoogleCodeExporter]

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?

Original comment by shadowof...@gmail.com on 24 Jan 2007 at 6:56

[GoogleCodeExporter]

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

Original comment by si...@gmail.com on 25 Jan 2007 at 6:44

• Changed state: WontFix