It has been almost year since the last post, and with OSX Yosemite just around the corner, I guess it’s time for a small update on how things have been going for the past year.
First of all, if you don’t want to read what have been happening for the past year and a rant about it, just skip the next 4 paragraphs…
So, lotta time went by, and with OSX Mavericks, there’s now a couple releases where this subject have been dormant. Thing is, with Mountain Lion, my Fuse4X + NTFS-3G setup continued working fine, as did my MacPorts setup, so I had little incentive to give it some update love, even though there were enough reasons that I’d need to do that eventually (more on that on the next paragraph). But then, after postponing for awhile, I’ve finally bit the bullet and installed OSX Mavericks – only to find out that my MacPorts setup was no longer functional, and my NTFS-3G mount scripts overwritten. That last part was actually expected and easily fixable, but now that I had a MacPorts setup to fix, I decided to move on and update my Fuse4x / NTFS-3G setup as well.
As I mentioned in the comments of the previous post on this subject, I’m providing a binary image with an installation of the latest NTFS-3G build (January 15th of this year) that’s available on MacPorts repositories.
It was built on my MacBook Pro running OSX Lion (10.7.3) using MacPorts, and tested on a clean (meaning, no development stuff installed) MacBook Air also running Lion. As you can see, my test base was kind of narrow, so I welcome feedback on how it works on earlier versions of OSX (though I don’t expect it to work, and neither will support anything before Snow Leopard).
This binary image is for installing NTFS-3G only – it was compiled against Fuse4X, and so I’m pretty sure it’ll work only with that, and obviously, you’ll have to install it before NTFS-3G – you can grab the install image for Fuse4X here.
Once you’ve installed Fuse4X, grab my NTFS-3G binary install image here and open it. It’ll have 3 files inside. Install the the .PKG file. Once it’s installed, then just double-click the “Switch” script on the install image, that’ll setup the mount script so NTFS volumes are automatically mounted with NTFS-3G. That script is named “Switch” because if you execute it again (having executed it once), it’ll switch back the mount scripts so the native/default OSX NTFS driver is used for mounting. The switch script will also come in handy once there’s an OSX update that might overwrite the mount script with the default mount_ntfs binary from OSX – happened to me once, but I can’t remember which update it was; though it hasn’t happened again since, you never know what Apple will put out on every update, so watch out. Anyway, if an update overwrites the mount script, just run the Switch script on the install image again and it should fix it. The third file, the “Uninstall” script, should be self-explanatory 😛
Ok, that’s it, so if you’re not a technically inclined / developer user, you can just and skip the rest of the post.
Estava vendo uma história no /. hoje sobre uma possível obra de DaVinci que foi descoberto por trás da parede onde atualmente está um outro afresco de outro artista, em Florença, Itália.
Como costuma acontecer, a discussão nos comentários acabou descarrilando um pouco pra fora do tópico (não que isso seja ruim – na verdade, acho que é o maior charme de ler /., é onde se aprende mais e se vê as discussões mais fascinantes), e acabei tropeçando num comentário que chamou minha atenção pois é mais ou menos a mesma visão que tenho sobre como a arte é enxergada hoje em dia.
So, I was browsing around the other day looking for a solution to disable this horrible behavior OSX has of littering volumes with these dot-something files. While I couldn’t find a solution suitable for all types of these files, I found something interesting – Asepsis. What a fitting name!
It basically forces OSX to store all .DS_Store files on other volumes on the internal HD (where OSX is running), where these files would otherwise be stored on the volumes themselves. DS_Store files are basically a way for the Finder to store file metadata (that’s usually relevant only to OSX itself) in a portable way – meaning these DS_Files aren’t necessary on an HFS formatted disk because the filesystem has builtin support for storing these metadata.
So, Asepsis is nice because, while still preventing the littering of those .DS_Files all over the target volume, it still allows OSX to store file metadata from these external volumes even if the filesystem on them are not directly compatible with OSX (which is the case of NTFS, FAT and network mounts).
There’s this for network volumes, but for network volumes I’d rather have it sorted out on the server: doing this tweak or installing Asepsis on every Mac workstation on the LAN at my work would be a PITA – although I’m the admin for the network there, supporting those Macs would be more hassle than it’s worth, and I already get paid too little as it is (the network is split in about 20% Macs and the rest Windows stations, so the Mac guys have their own support guy for when things go haywire for them). I’ve tried blocking the creation of these OSX metadata files on Windows Server, but then OSX starts acting weird and refusing to do some stuff, so for now my solution is to just remove those dot-files every once in a while.
If there’s something to hate on Macs, from an IT management point of view, is the disruptive and messy way Apple chose to interact with other tech. It’s irritating.
Update 2: Check out this post (and this one for OSX Mavericks) for a prebuilt binary installer for NTFS-3G that can be used with the Fuse4X solution detailed below (i.e., if you’re not willing to go through all the steps of installing XCode, MacPorts, etc. that’s detailed below, you can just install Fuse4X binary (from here) and the NTFS-3G installer I’m providing on the post linked above).
Update: Thanks to some suggestions from Marcos on the comments below, I kicked myself back into trying to solve the mount problem with uids/gids on fuse4x / ntfs-3g. I’ve updated the script below, it now improves things somewhat. It’s still not perfect – it’ll work fine if your user logs in automatically, otherwise, it’ll try to wait for 20 seconds (adjustable on the TIMEOUT variable) until the user session is active and it picks up the user id from the session started, and if that too fails, it falls back to the old behavior (fixed uids/gids). There’s also an alternative solution for that provided by Marcos on the comments area of his post, check it out (in portuguese – Google Translate is your friend).
It’s a well known fact that OSX had NTFS read support for a long time, but write support could only be easily enabled either by:
- Buying third-party solutions, from Paragon or Tuxera. The latter is actually a product-fied version of the open-source solution mentioned below;
- Enabling manually on the native driver by messing around with system files. That option is known to be very unstable and can potentially corrupt your NTFS partition, so it’s strongly NOT recommended. Also, this worked only on early versions of Snow Leopard – apparently Apple disabled this “feature” later (though it seems nobody tried it again with Lion). It’s obvious that with this move Apple was clearly saying that the driver is not reliable for write support and should not be used as such.
- A port of MacFuse and NTFS-3G provided by Tuxera. The official versions are old and don’t work at all on 64-bit kernels (i.e. Lion).
On the last case, there are unofficial builds of MacFuse that work on 64-bit kernels, but not without a few issues – this post will outline the steps on getting this unofficial version of MacFuse working along with the older version of NTFS-3G (the version that was still free, before Tuxera went completely commercial with it). Also, while most of the procedures detailed here were tested in my OSX Lion installation, it should in theory work on Snow Leopard too, I just have no way to confirm this at this time. Feedback is welcome on that.
I’m also going to outline the steps on getting to work a solution based purely on MacPorts, a package manager for OSX that works by downloading the source code to a package, compiling it on your machine, and installing it. That solution works fine for the most part, with only a small caveat, that may or may not affect you depending on how you work with your Mac. In my opinion, though, this solution is also more robust and (hopefully, once the small kinks get worked out) bug-free solution and easier to maintain and update (thanks to MacPorts) on the long term, and I hope it gets noticed by the developers involved because of that. I’m personally using this solution right now, but due to it being somewhat more cumbersome to setup, it probably should be taken as geared towards power users – if you want something a bit easier to setup, you’re probably better off with the MacFuse + Tuxera’s NTFS-3G solution presented below.
“Este não é o post que você está procurando” – Cavaleiro Jedi
O post detalhando essa odisséia vêm à seguir, em inglês. Calma, tenho motivos pra isso, que direi à seguir. E já que estamos no tema do idioma, aproveito pra observar que, dependendo do caso, vou postar outras coisas em inglês de vez em quando, se eu julgar que o conteúdo pode ser útil para visitantes do exterior, como é este caso. Nesses casos, Google Translate é seu amigo. 😉 O que vem à seguir é mais um desabafo, então pode pular direto pro próximo post se quiser ir direto ao assunto.