MacFUSE + sshfs + underlying SMB mount = fail

One of the things I’m trying to do is mount remote filesystems on my Mac using MacFUSE and sshfs. In short, the idea is you use ssh/sftp to connect to a remote system and “mount” its filesystem (using the SSH connection) so that it appears as a mounted volume on your local machine. In general, this works great; you only need SSH access to the remote host–not SMB, CIFS, or any other standard, but perhaps firewalled, network file sharing protocol.

But, what if the remote filesystem you want to mount is actually a mounted SMB share? You would think it should “just work,” right? It kind of does, sorta. But, only sorta.

I start out by using sshfs to mount the remote filesystem:

dossy@shiny:~$ sshfs foobar:/share x -o volname=x

Nothing surprising: this just works as you’d expect. I’m mounting the subdirectory /share on foobar to my local mountpoint named “x” as a Mac volume named “x”. Lets make sure we can write to it:

dossy@shiny:~$ cd x
dossy@shiny:~/x$ ls -la
total 8
drwxrwxrwx  1 root  wheel  4096 Sep 13 20:40 .
drwxrwxrwx  1 root  wheel     0 Sep 13 18:23 ..
dossy@shiny:~/x$ echo "This is a test." > test.txt
dossy@shiny:~/x$ cat test.txt
This is a test.

There, we can write to this remote filesystem just fine–this is great! But, this was all from the shell, what about from the Finder? Ahh, this is where things start to suck hard. I create a small test file called “suckage.txt” and try to copy it to the sshfs mount:

Copying a test file to my sshfs mount in Finder

Attempting this copy operation results in this error dialog:

Copy: The operation cannot be completed because you do not have sufficient privileges for some of the items.

Say what? I don’t have sufficient privileges? Finder, you’re crazy. Watch this:

dossy@shiny:~/x$ cp ~/Desktop/suckage.txt .
dossy@shiny:~/x$ ls -la
total 16
drwxrwxrwx   1 root   wheel     0 Sep 13 21:49 .
drwxr-xr-x+ 35 dossy  staff  1190 Sep 13 20:57 ..
-rw-rw-rw-   1 root   wheel    20 Sep 13 21:51 suckage.txt
-rw-rw-rw-   1 root   wheel    16 Sep 13 20:45 test.txt

Looks like I had privileges just fine–why couldn’t Finder copy the file? I suspect it has a lot to do with the crazy AppleDouble nonsense that Finder messes with, none of which happens when I just copy the files in a shell.

I’ve spent at least an hour playing Configuration Option Bingo (you know, when you try turning on and off all the various configuration options until you get the permutation that solves your problem, at which point you want to jump up and shout out “BINGO!”) … with no luck. I’ve tried “-o noappledouble” and the other obvious things. I’m now giving up and blogging this, hoping that someone out there has figured this out and might share their secret; I sure couldn’t turn up anything useful by Googling, that’s for sure.

Tags: , , , , , ,

Looks like I’m officially a “switcher”

So, I finally broke down and ordered myself a 15″ MacBook Pro from MacMall.com on Tuesday last week, and it arrived the next day (!) … and I’ve been installing apps and migrating my data over to it since. I guess you can officially call me “a switcher” as I’ve moved all my data off my old laptop onto this new one, and the old one is going to get reformatted and will become my wife’s.

Part of switching to a Mac means looking for new blogging software. I previously used BlogJet 2.0 on Win32, but now I’m trying out ecto 3 beta for MacOS X. I definitely think it’s going to take some getting used to but I can already tell it’s much better than BlogJet was. However, I can definitely see needing to customize ecto to my liking before I can feel really comfortable using it.

Have you switched recently? Got any good tips that I might want to know about? Things to avoid? Tell me about it in the comments …

del.icio.us/dossy links since July 28, 2008 at 09:00 AM

del.icio.us/dossy (RSS) links since July 28, 2008 at 09:00 AM:

Migrating from Windows Pidgin to MacOS X Adium

In replacing my aging Dell C840 laptop with a new MacBook Pro, I need to switch from using Pidgin to using Adium for IM. Since they’re both based on libpurple underneath, I figured there ought to be a way to migrate my settings from one to the other. As it turns out, it might be possible.

Your libpurple settings are stored in %USERPROFILE%\Application Data\.purple on Windows. Similarly, they’re stored in ~/Library/Application Support/Adium 2.0/Users/Default/libpurple on OSX. If you simply replace the blist.xml and accounts.xml that Adium creates with the ones from Pidgin, that should work, right?

Wrong!

Adium’s preferences are stored in plist format which, can now be easily edited since 10.5 (Leopard), even through AppleScript. Luckily, there’s even a simple utility called plutil that can convert from XML to binary plist format.

It would be pretty straight-forward to write a simple script that parses the libpurple XML and wrote out the appropriate plist XML then use the plutil tool to convert to plist binary format – but, I’m feeling lazy and only have about 10 accounts to migrate, so I’ll just do it by hand. Of course, there’s more to migrate than just accounts (old chat logs, etc.) but it’s not enough to overcome the inertia of my lack of caring to do it right now.

Tags: , , ,

Christina at DownloadSquad likes Blackbird!

It was only a few months ago that Brad linked to Twitter Karma over at DownloadSquad, but a few days ago Christina surprised me by putting Blackbird at number 5 on her list of 10 awesome BlackBerry apps. She writes:

Blackbird — I used to use Twitterberry to update my Twitter status from my phone, but now I’ve switched to Blackbird. The interface is cleaner and it feels faster. I miss the user icon pictures from Twitterberry, this is still my favorite way of using Twitter.

Man, I love those DownloadSquad bloggers! Thanks for the love, Christina.

Tags: , ,

del.icio.us/dossy links since July 14, 2008 at 09:00 AM

del.icio.us/dossy (RSS) links since July 14, 2008 at 09:00 AM:

del.icio.us/dossy links since July 7, 2008 at 09:00 AM

del.icio.us/dossy (RSS) links since July 7, 2008 at 09:00 AM:

“Monsters are real. But the real ones are not bulletproof.”

I haven’t been actively reading my feeds, so when I fired up the reader today, I saw Bill Kocik’s pro-gun essay in his blog.

Personally, I:

  • Do not own my own firearm.
  • Do not like the idea of anyone using firearms.
  • Recognize that firearms exist and will never go away.
  • Believe that someone is less likely to perpetuate a violent crime if the odds that they will get shot in retaliation increases.
  • Believe that in a world where guns are readily available, a steady equilibrium of safety will eventually be reached–perhaps, unfortunately, after much death by guns. Those left remaining and still alive will learn to co-exist safely together.
  • Do not believe that fewer guns is the answer. As long as the balance of power leans in favor of criminals, no one can be safe.
  • Am thankful that there are people who responsibly own and carry firearms, so that I don’t have to.

Wishing that we could live in a world without firearms is just that: wishful thinking. The reality is that guns have been invented and that can never be undone. The only rational path to safety is reaching the point where enough people are carrying firearms so that using one inappropriately will be dealt with swiftly and abruptly: with deadly force.

Tags: , , , , ,

Google’s Protocol Buffers …

… or, “Everything old is new again!

Yesterday, Google announced Protocol Buffers, their data interchange format and API libraries. Before I say anything else, I want to say I’m glad they did it: it uses neither XML nor ASN.1, which means someone at Google has a clue.

What bothers me is that yet again, what was old is new again–their on-the-wire encoding of the data is simply TLV and AOL has been using SNAC/TLV for at least 15 years now. However, AOL’s SNAC/TLV covers a lot more use cases than what Protocol Buffers does. Then, there’s AOL’s FLAP transport for SNAC which Google hasn’t even approached. There’s still a lot more “work” that Google has to do–or, just use what AOL’s already proven works.

Of course, Google gets the community pat-on-the-back because they released this publically whereas AOL still has it hidden behind some proprietary lock and key. AOL, this is another technology opportunity missed: you could have continued to keep your internal, proprietary technology relevant if you’d simply opened this stuff up, first. Now, you’ll have to continue to replace it–at a huge sunk cost–with “standards-based implementations.” Oops.

In the end, I’m glad to finally see someone not blindly drinking the XML Kool-Aid. Maybe there’s hope, yet.

Tags: ,

del.icio.us/dossy links since June 30, 2008 at 09:00 AM

del.icio.us/dossy (RSS) links since June 30, 2008 at 09:00 AM: