How do deal with Mac's Display Names concept when coding at the OS level?

Sounds like there may be two name-like values for the same device. I don’t know the answer though so I’ll refrain from further conjecture.

[ Update ]:

For the record, the main system drive (named “Macintosh HD” by default) mounts in the OS simply as ”/”. The problem I’m having is with external firewire drives, which get mounted under the ”/Volumes” directory by whatever name they’re given by the user.

So, the point behind my example above is correct… but the example names I chose to make the point were poor selections for anyone who’s experienced in this area.

Hope this clears up any confusion I may have inadvertently caused.

What’s your actual scenario and concern? That you may store the name of a volume, but then the user or some process may change it at some point?

@Zaku, not that the user changes the Display Name… but that the external volume might mount in the future using a different name… which would screw up something simple like:

cp /Volumes/FirewireDrive/here/* /Volumes/FirewireDrive/there

See, if “FirewireDrive” mounts in the future as “FirewireDrive 1”, then that cp command wouldn’t be able to work.

The apparent name change is not done by the user, but is something automatic in the OS when it strikes some kind of conflict (not sure the parameters of that, though). I’ve seen it happen several times.

It looks to me like the name for a device is set and retrieved from the device itself so you’ll always have a problem with accessing by name (user might change it, OS might mount it as you describe).

You also will have the same problem with regards to which device id is given; your external drives could be any of /dev/disk*s* depending on the order they were mounted.

All I can think of is to suggest placing a file on the root of a device to identify it to your app. For instance, Time Machine places a file on device roots as metadata named .com.apple.timemachine.supported. You could use some sort of a unique id or hash. I’m curious to see what you find as there might be a way to do this “properly”. Good luck.

@Paul, that’s interesting, I’ll poke around. Would be cool if I could perma-set the name for the OS, like Time Machine does.

I think I see the cause of the problem. At the OS level, there’s a directory with the same name as the filesystem originally had.

Makes sense then that, when the drive went to mount, it couldn’t use the same name (occupied by that dir), and so it stuck the ” 1” on the end of the mount name. Of course, the Display Name is unchanged so the typical end user is unaware.

Now, why the flip is a directory getting created with the name of the filesystem?!? If I had to guess, something’s going awry with my clone backup.

I like paulc’s suggestion, though it could be not a special file in the root of the device, but simply whatever would exist for it to be appropriate for your program to do what it does. Like, if the expected volume/path doesn’t exist, check all volumes for the existence of a /there or maybe a foo.config file in /there.

If you’re bent on avoiding the variation in names, couldn’t you refer directly to the device in some way (ie. /dev/disk0s2)? There should be a toolbox routine somewhere that will give you the name of a volume container when given the specific hardware device name, right?

df | grep | cut with appropriate params would likely do the trick.

I do more Solaris/AIX/HP-UX scripting in enterprise environments, so this whole filesystem-name-can-change-whenever business is weird to me.

From your typical end-user perspective, it allows things to “just work”, which is cool. OTOH, dealing with the aftermath of such problem (like a full disk and clone backup failing with non-specific error) is very not intuitive and kinda crazy.

@chaosrob, external devices won’t always be assigned the same device IDs so its the same problem (see my earlier answer).

@paulc, would work for internal devices, tho, no?

Fellas, have you ever witnessed external (in this case Firewire 400) drives magically disconnecting/unmounting and reconnecting/mounting on their own? I’ve seen it happen a couple of times, usually around the midnite hour (plus or minus an hour or two).

I think that might precipitate this naming clash problem.

I haven’t seen that, but I haven’t been looking. Seems to me though that if you intend to support removable drives coming and going, you may as well just back off your assumptions and design for the scenario that you respond to any new or removed or renamed drive in a consistent way. A bonus is you could get elegant response to drive failures, deletions, system reconfiguration, etc.

Nope… these are permanently attached to a desktop mac. It’s a weird thing.

Um, if they’re permanently attached, won’t the device enumeration generally stay the same? Also, if they’re permanent, why is the volume name changing so often?

The “magical dis- and re-connect” I cannot explain.

But I know what the result was this time.

I’ve got CarbonCopyCloner rigged so that it makes a differential backup of my bootup volume every nite. It’s set up to put the backup on a dedicated partition named “Backup HD”. The filesystem being found at ”/Volumes/Backup HD”

Enter the mystery dis-/re-connect of the destination volume.

See, I think what happened is that the drive did its hinky thing and disconn’d. CarbonCopyCloner (running rsync behind the scenes) probably then created the dir it needed to continue the differential. It did the equivalent of a mkdir ”/Volumes/Backup HD”.

And where’d that new directory (not filesystem) get created? On the root fs, that is, the main, bootup volume.

Then, when the actual drive did its mysterious re-connect, the Mac OS found the destination directory already in place. So in order for things to Just Work™, the OS mounted the disk back naming the filesystem as ”/Volumes/Backup HD 1”.

At which point, all subsequent differential backups of the main drive were getting saved back to the main drive… eventually filling it up. At which point, I finally took notice.

Removing the extraneous directory ”/Volumes/Backup HD” and renaming the filesystem ”/Volumes/Backup HD 1” to its original name got me back on track. (That and ensuring that CCC could continue with its planned differential backups.)

So, why the flip is my permanently connected external firewire drive apparently dis- and re-connecting some times? I dunno.

How do I prevent the above scenario from recurring? I dunno.

Is this a case where the Mac’s ability to Just Work™ might be a bad thing for your typical user? Yah, probably.