Sunday, October 12, 2008

NTFS-3G 1.5012

What's new:
  • Version 1.2926-RC is released unchanged as stable. The NTFS-3G driver is able for unlimited file and directory creation and removal as the result of 13 years continuous development with the help of hundreds of contributors over these years.
Download NTFS-3G 1.5012 [ublio] (performance patches applied)
Download NTFS-3G 1.5012 [stable]

Packaging, patching, some OS X-related development and testing is done in the context of my development efforts with the Catacombae projects.

Requirements: Mac OS X 10.4/10.5, a PowerPC or Intel computer, MacFUSE 1.7 or later installed.
This package has been tested with OS X 10.4.11/Intel and OS X 10.5.5/Intel.

Information on how to install and use NTFS-3G for Mac OS X can be found in the User Guide.

Known issues:
  • Files with filenames created in Windows containing international characters with accents, umlauts and similar dots and lines, or filenames with korean characters might seem unreadable in the Finder. This is because Finder apparently expects all filenames to appear in unicode decomposed form, while NTFS allows both composed and decomposed form filenames. This issue is hard to solve in a pretty way, but you should still be able to access these files when using the Terminal. For me, copying the affected files to a HFS+ drive using the command "cp" worked fine.

  • After installing ntfs-3g, all NTFS drives will disappear from the "Startup Disk" preference pane. Disabling or uninstalling ntfs-3g brings them back. I don't have a solution for this, but you can still choose your startup drive by:
    • Holding down the Option key during boot (or Alt for non-Apple keyboards).

    • Intel users only: Install the rEFIt boot manager for better control of the boot process.

    • Using the command line utility bless (see man bless for more information)
    If you have any information on a pretty way of solving this issue, I'd love to hear about it.

Sources:
ntfs-3g 1.5012 (patched)
ntfsprogs 1.13.1
fuse_wait.c
ntfs-3g_daemon.c

35 comments:

Unknown said...

I just wanted to say thank you for providing the mac packages of NTFS-3G. The recent versions work very well for me and our company.

Anonymous said...

As I can recall, in older builds, there was the problem, that NTFS BootCamp Partitions did not become writable with this driver and that there have been significant longer (2s or so) startup/shutdown times.

Are these things still present in this version (ublio)?

Anonymous said...

The NTFS drive that disappears from the Startup Disk Pane has been solved within MacFuse a long time ago


http://code.google.com/p/macfuse/issues/detail?id=34&can=1&q=bert

Maybe you can find more info here!?

Erik said...

vysyus:

Great to hear that it works well for you. (:

Erik said...

Chrigi:

I'm not sure which older builds you are talking about... my NTFS-3G package has always been about enabling writing to Boot Camp NTFS volumes (it's what I mainly use it for myself), and I can't recall that there has ever been a problem with that.

The significantly longer shutdown times (30 seconds, not 2) was the result of an even more serious issue... that the ntfs-3g driver never unmounted cleanly when rebooting. It has since been adressed, and it shouldn't be a problem anymore.

Erik said...

bert:

Well... it's not apparent to me what triggers the Startup Disk prefpane to display a volume.
The workaround done in MacFUSE is intresting but only seems to apply to that configuration.
I don't define an NTFS key in my package, but rather an NTFS-3G key, so the solution to the MacFUSE problem doesn't apply to the NTFS-3G package.

Anonymous said...

Thank you for the great response :) Then I've got no worries installing it.

Anonymous said...

thanks (as usual) for the work you do for us final users !!!!

Anonymous said...

After following the development of this driver for several release, I decided is time to say thanks for doing it.
I exploit the occasion to report that on my 10.4.11 PPC macosx, this ntfs-3g is quite cpu consuming. I have a 1.5Ghz G4 and the ntfs-3g process often uses more than 30% of cpu for tens of minutes, with quite long periods of neary 90% of use. Is this normal? this happen even if I am not accessing the ntfs drive.
Thanks
roberto

Erik said...

kOoLiNuS:

You're welcome. :)

Erik said...

Anonymous, October 23, 2008 2:45 PM (roberto):

Often when the ntfs-3g process is consuming a lot of CPU when you're not accessing the drive, it's because of Spotlight, which has a bad habit of indexing all drives that it can see.
Check if the mds process is also working when ntfs-3g is consuming CPU. (mds is the metadata server that Spotlight uses)
It's not normal that ntfs-3g should consume any cpu cycles otherwise, when mds is not active.

You can disable Spotlight indexing for the volume by adding it as an exception in the Spotlight preference pane.

Roberto said...

you were right, the mess seems to be originated by spotlight. however the privacy setting of osx 10.4 spotlight preferences panel seems unable to exclude a drive form the list of path to be scanned.
as such i did have to add an empty file named .metadata_never_index in the root directory of my drive.
this seems to be able to stop 10.4 spotlight from indexing the drive, and seems to work.

Roberto said...

the annoying this now is that somehow the volume name is messed up.
finder icon still display the name it had in the past: "250", but it get mounted as /Volumes/Untitled.

I was wandering to user ntfslabel to relabel the drive, is this safe?

Roberto said...

i did nothing, and now the volume name is back ... is this a bug?

James (Jeffrey) T Wang said...

please see my bug reporting starting 20/10/08...

http://forum.ntfs-3g.org/viewtopic.php?p=4028#4028

No idea how to fix these problems.

Cheers
Jed

Erik said...

Jed:

I just replied to your post at forum.ntfs-3g.org.

James (Jeffrey) T Wang said...

okay thanks, can continue discussion there instead...

nobody said...

For special characters in filename that is in NFC, is that impossible to convert them into NFD on the fly?

Erik said...

kz:

Not impossible.. but consider the situation when you have mixed composition form file names in a directory... which composition form should the driver choose?
Inevitably, there will be situations where some files will not be displayed because of composition form conflicts, as it's not a one-to-one conversion. The string "Hölö" can be represented in 4 ways: H-ö-l-ö, H-o-¨-l-ö, H-ö-l-o-¨, and H-o-¨-l-o-¨ . What if you have all of these filenames in a directory? NTFS allows it. The hypothetical auto-decomposing NTFS-3G driver would have to allow access to only one of them.

I just wish Apple would fix the Finder... but that doesn't seem to happen. Just as Microsoft aren't fixing Explorer's limitations (such as the ridiculous MAX_PATH limit, which is really trivial to overcome).

Anonymous said...

I wasn't able to open the link to download the ntfs file???
help me please!

Erik said...

Anonymous, November 6, 2008 7:21 AM:

That shouldn't be a problem, but you can try to download it from here instead: http://sourceforge.net/project/showfiles.php?group_id=201032&package_id=250950&release_id=632743

nobody said...

Erik,

Yes. Mixed composition in NTFS can be dirty problem.

But, well, what about at-your-own-risk option? So to say, 'I want this mount point to be auto-decompositing' option for mount command?
Despite of liberal NTFS filename policy, almost everyone has just single sort of composition type for a single filesystem, I do suppose.
Then it will be worth to support auto composition convert that is specified by user.

For example, after I mentioned this conversation on another local linux community website, someone put a python fuse mount app that auto-decomposite.
( http://kldp.org/node/99731 , but you may can't read the Korean characters :p )

I think auto-decompositing will greatly help mac-windows crossed user, especially for Korean.

Erik said...

kz:

Yes, I realize that it would be helpful.
I'll try to find time to investigate how easily this can be done.

Unknown said...

My computer is Dual 1.8 GHz PowerPC G5, Mac OS X 10.4.11. The external hard disk is Beyond Micro Model BMMDU2 with 250G. I converted its format from FAT32 to NTFS. I installed NTFS-3G1.5012 [ublio] in the Mac and transferred approximately 80G of data from the Mac to the external hard drive. The transfer took approximately 120 hours to complete. Opening a folder or scrolling is now much slower than when the format was FAT32. Thank you for writing the software and making it available. I look forward to seeing an upgrade.

Anonymous said...

ntfs-3g 1.5130 released

Anonymous said...

I'm having an issue with files with Japanese characters not being opened correctly. I was wondering if there was a work around for this problem ? Thanks in advance for any help

Unknown said...

Raymond said...

ntfs-3g 1.5130 released.

I downloaded it but could not install. Please tell me how.

Anonymous said...

Ching said...

on www.ntfs-3g.org there supplied only the source code and linked to binaries for operating systems. For Mac OS X you need binaries e.g. supplied on this page. I think Eric build new binaries soon.

Unknown said...

Thank you, Raymond. I do hope to see whether the new version can make the external hard drive run faster. As of now, I regret having formatted it to NTFS-3G because it crawls like a turtle.

Erik said...

Hey all. I just released the 1.5130 package.

Erik said...

Ching:

There won't be any performance specific improvements in the new version.

What kind of tranfer rates do you get? In numbers...

Erik said...

Help me please:

What kind of problem are we talking about? Could you give an example?
I haven't heard of anyone with issues with japanese characters.

Unknown said...

Erik:

As I said in my first conversation, it took 120 hours to transfer 80G of data from Mac to the external hard drive. I am not as much concerned about the transfer rate now that the transfer is finished. What bothers me now is the slow scrolling and slow opening of folders. It just seems to be taking forever to do these basic tasks.

Erik said...

Ching:

I have never heard about this problem before... does the ntfs-3g process use a lot of CPU when this Finder slowdown happens? (Check this with Activity Monitor)

This may be a PowerPC specific issue, since I haven't heard of it before. Unfortunately I won't be able to address PowerPC specific issues until someone provides me with a PowerPC mac for testing. I can currently only compile the code for PowerPC and hope that it works.

I would advice you to upgrade to the latest version (1.5130) and the latest MacFUSE version. Also, check if there's any difference in behavior between the "ublio" and the "stable" build of NTFS-3G.
Please post subsequent comments about this issue under the 1.5130 post, so I know you're using the latest version.

Unknown said...

Erik:

To avoid the problem, I bought a new external drive (FAT32 format) with automatic backup. It took about 7 hours for the backup program (NT3 Shadow) to transfer the 80G data from Mac. The drive is running smoothly.

I have decided to use the old drive exclusively with PCs, with which it runs well. So, I won't be able to provide any more testing results for the Mac-NTFS-3g issue.