System – Walt-O-Matic

NTFS on OS X

Trying to write to an NTFS volume on OS X, and all you find are third party packages and complicated config file manipulations asking you to reboot? Do this….

Every once in a while someone brings over an external NTFS formatted drive and plugs it into my Mac to exchange some large data sets. While the Mac can easily read NTFS, it doesn’t appear to have the capability to write to that file system.

Appears is the operative phrase.

If you search for a solution in the open, you’ll find companies selling commercial products, drivers, and mounters. Some people have posted complicated looking instructions telling instructing you to mess with low level system files, that may or may not exist, ending in a full system reboot that typically solves the problem for that lone drive.

Here’s the generic no-software required solution.

First connect your NTFS drive to the Mac, it’ll mount with some name like “My Disk.”

Open a Terminal window and enter the command:
$ mount

The mount command will tell you what drives are listed. Find the one that has your drive name listed in it and copy the device name:
/dev/disk1s2 on /Volumes/My Disk (hfs, local, nodev, nosuid, journaled, noowners, mounted by me)

Now eject the drive, but don’t disconnect it from the machine.

Go manually create the directory (shown in bold above); this is where the mount point will be:
$ cd /Volumes
$ mkdir My\ Disk

NOTE: The backslash escapes the next character, in this case allowing a space in the directory name.

Now, mount the drive as read-write using this command:
$ sudo mount -o rw -t ntfs /dev/disk2s1 /Volumes/My\ Disk

Make sure that you’ve used the same device location you copied down the the prior steps.

At this point your drive should appear on the desktop, and you ought to be able to read and write to it just fine. No rebooting necessary!

Note that you can get to it from the Terminal as well:
$ cd /Volumes/My\ Disk
$ ls

Note that sometimes Finder may act a little wonky with timing problems and a huge file. Apparently the underlying Unix system has no problem. You can copy a big file to the drive:
$ rsync –progress SuperBigFile.zip /Volumes/My\ Disk

Or a whole directory:
$ rsync -r –progress LargeDeepDirectory /Volumes/My\ Disk

When done, make sure you are not running any programs that are accessing the drive or have their current directory set to the drive:
$ cd /Volumes

Then, eject the drive normally, or unmount it from the command line — your choice.
$ sudo umount /Volumes/My\ Disk

Full disclosure and warnings: This was tested on OS X 10.6.5, though support has been around to do this for a while. And, any time you’re doing something that deals with questionable file system access, make sure there’s nothing on the drive you don’t mind losing. Have a backup. There’s always a slight risk, but it’s very close to zero — why state all this? Because I assume no responsibility if something goes wrong.

Reactive Framework conflict (SOLVED)

The type ‘System.IObservable exists in both ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’ and ‘c:\Program Files (x86)\Microsoft Reactive Extensions\Redist\DesktopV2\System.Observable.dll’ (SOLVED)

During an upgrade of a C# WPF application that was using Reactive Extensions, I ran into this compile error:

The type ‘System.IObservable exists in both ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’ and ‘c:\Program Files (x86)\Microsoft Reactive Extensions\Redist\DesktopV2\System.Observable.dll’

This is roughly the same kind of Defined in Multiple Assemblies problem as I faced before. (Solution provided.)

In this case, the System.Observable.dll was pinned to the 3.5 release of the Reactive Extensions.

The solution was to:

Download the .NET 4.0 version of Reactive Extensions (Rx_Net4.msi).
Install it.
Remove System.Observable from the project.
Re-add the System.Observable to the project, being super careful to select the latest version

Defined in Multiple Assemblies

The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias … mscorlib.dll and System.Core.dll. SOLVED!

Today I migrated a C#/WPF project in Visual Studio 2010 from .NET 3.5 SP1 to .NET 4.0. Immediately the compile failed issuing this set of errors:

The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias; using definition from ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\mscorlib.dll’
The predefined type ‘System.Func’ is defined in multiple assemblies in the global alias; using definition from ‘c:\Program Files (x86)\Reference Assemblies\Microsoft\Framework\.NETFramework\v4.0\System.Core.dll’

To resolve this error involved understanding a little bit more about C#, .NET, and the Common Language Runtime (CLR).

According to C# 4.0 In A Nutshell from O’Reilly Press, on page 181 it says:

Some of the .NET types are used directly by the CLR and are essential for the managed hosting environment. These types reside in an assembly called mscorlib.dll and include C#’s built in types, ….

At a level above this are additional types that “flesh out” the CLR-functionality, …. These reside in System.dll, System.Xml.dll, and System.Core.dll, and together with mscorlib the provide a rich programming environment….

So mscorlib and System.Core are both needed. This begs the question, why is Func declared in both and thus causing a conflict? Or is it?

Further on in C# 4.0 In A Nutshell from O’Reilly Press, on page 183 in a general note it says:

A notable exception is the following types, which Framework 4.0 have moved from System.Core to mscorlib.dll:

The Action and Func delegates

…

This suggests a case exists where mscorlib is from our current .NET (the later one has Func), and System.Core is coming from the old one (which is where Func lives for that version).

How is this possible? It’s our projects fault.

This question on StackOverflow provides some insight; check out Simon‘s answer.

Right-click the project and select Unload Project
Right-click the project again and select Edit Project
Scroll down in the XML to find the ItemGroup element; it’ll have Reference elements insider of it.
Locate the Reference element that has Include=”System.Core” as an attribute.
If it has other qualifiers, remove them. If it has a TargetFrameworkVersion subelement remove it.
Save the XML.
Right-click the project and reload it; try a build now.

In my case, I had an entry that looked like this:

Removing the TargetFrameworkVersion, shown in red above, un-pinned the dll from the older .NET framework and things worked just fine.