For the time being - until I get some extra code cash, I’ve switched back over to Eclipse, as I’ve been doing a good bit of Flash and Javascript coding, and my dev box is a Windows 2003 virtual machine on a server somewhere in California, on which I can also handily run Eclipse. So, until I really optimize my process, I’m sidelining TextMate a bit (as my trial period is about done). So, I’ve been writing some Ant build scripts to optimize the process (more on that perhaps a bit later), and have configured a couple of targets in my flash project to auto-install my distribution tar.gz file onto my dev box.
This works great most of the time — I connect to the dev VM via a windows share using an SMB connection from my Mac, so the Ant scripts point to the remote box as /Volumes/D$. Unfortunately…
…my router is flaky and times out my cable connection about 2-3 times a day, rendering my connection to my dev VM non-existent. Here is where the slight problem occurs - the mount-point on the Windows box is D$, so when OSX makes an SMB connection, it creates a D$ temporary folder in the /Volumes directory on the Mac. When the connection is unexpectedly broken, the clean-up to remove that directory fails, and when the share is reconnected, OSX creates a new version of the directory, as “D$-1″ (or -2, -3, etc.), which breaks the Ant scripts.
The solution, simply, is to open the Terminal after such an unexpected disconnect, and perform the command:
sudo rmdir /Volumes/D$
to remove the unmounted directory.
I have tried to connect directly to the smb share in the terminal utilizing the specific share directory:
sudo mount_smbfs -W workgroupname //username@ipaddressofserver/D$ /Volumes/D$
but unfortunately, you have to su in the terminal (switch to root user) in order to access the contents — otherwise the directory is read only. When running the Ant scripts from Eclipse, you don’t have root user permissions, and copying to the remote machine fails. Anyone have any thoughts on this?
2 Comments
You should know who to go to with a question like this…
Mount the volume with a mask that is writable by your logged in user, or create the directory in advance. For example:
sudo mkdir /Volumes/D$
sudo chmod 777 /Volumes/D$
sudo mount_smbfs -W workgroupname //username@ipaddressofserver/D$ /Volumes/D$
Or, a little cleaner would be this:
sudo mount_smbfs -f 777 -d 777 -W workgroupname //username@ipaddressofserver/D$ /Volumes/D$
Of course, 777 would be more aptly named “666″ because you should never really use it, but its a nice quick fix.
Ah, yes, cool. I actually came to the same conclusion and hadn’t followed up yet, although I was not aware of the ability to chmod the directory and its contents — that’s pretty nice.
The solution that I’m working with temporarily is an applescript application bundle that creates the directory wsd (windows share d) if it doesn’t exist (applescript for the existence test because I didn’t know the shell command and mkdir + chmod shell commands) and then runs the shell mount_smbfs command. When the directory is mounted, the applescript then pops an alert to let me know when its ready to go. More on this a bit later…