[macintologist]

I'm thinking of renaming my Macintosh HD and actually giving it a name. I'm afraid though that some apps that rely on support files will be broken because they are pointing to Macintosh HD/User/me etc etc instead of dynamically knowing that the hard drive is the hard drive no matter what.

[tooki]

No app should be that stupid. Especially on OS X, where each user has a different home directory.

Do it, see if it works OK, and if not, change it back.

tooki

[Fusion]

I always rename my hard drives and have never experienced any problems with ANY application.

It's completely fine to do.

[Chuckit]

Since Unix apps would call it "/" rather than "Macintosh HD," and those are the ones that tend to use literal paths instead of using aliases, I think you're safe.

[Weyland-Yutani]

Yeah, you'll be perfectly safe. Change the HD name as you like, when you like. Only UNIX apps could theoretically give you trouble, but they won't, because as Chuckit mentioned, they just go by / and call it a day.

On a tangent: literal paths became dinosaur-technology in the 90s. And now they are back with OS X!

Oh well. Maybe one day OS X will become as advanced as OS 9. Who knows. I'm not holding my breath.

cheers

W-Y

[ghporter]

As a computer science student in the 1990s, I was taught that literal paths were Bad Things™ explicitly because they tend to break things when any part of the path gets renamed. Code with literal paths is Clunky® and that means you shouldn't trust it to install where you want, save your files where you want, and otherwise behave itself. Very little code needs any literal path for anything, and such code is most likely found deep in the OS. Renaming your hard drive should have zero negative effect.

[Helmling]

Expecting a simple thing like renaming an icon to screw up the whole comptuer...How long out of the Windows world are you, I wonder?

Fear not, my HD's been named "Ophelia" since the first day I switched 3 years ago.

[macforray]

I'm new to Mac's as of 8/4/05. I renamed my hard drive as soon as I realized I could. No problems here.

[Randman]

Not only do I rename it but I use a transparent image for the icon.

[slugslugslug]

Originally Posted by Helmling

Expecting a simple thing like renaming an icon to screw up the whole comptuer...How long out of the Windows world are you, I wonder?

Or the OS 9 world. There were some apps back then that got all pissy (can I say "pissy") if you changed the name of the HD after the app was installed..

Fear not, my HD's been named "Ophelia" since the first day I switched 3 years ago.

Yeah, but the OP is asking whether any apps might use the literal path. Maybe he/she's already assuming that the Apple or bundled apps would behave, but some installed later wouldn't. So he's asking about something fundamentally different from changing it on the first day of owning the Mac.

That said, I think everyone else here is right. There probably aren't many, if any, OS X apps that will choke on this (if there are any, they're probably horrible to use in other respects already). Give it a shot. It won't destroy anything big...

[Weyland-Yutani]

Originally Posted by slugslugslug

Or the OS 9 world.

Well that is interesting. Because hasn't changed in the OS X world then has it? Perhaps you wanted to say "in the Macintosh world"?

It depends on the app of course and how it is programmed, not the OS. However this can be a part of how an OS works and OS 9 never used literal paths (on user level). Mac OS X uses literal paths on user level in some cases.

cheers

W-Y

[Cadaver]

I change the name of my PowerBook's drive all the time (still looking for a good name). Never a problem... and I even have FileVault turned on.

[milhous]

you'd be surprised that there is still commercial software out there that relies heavily on the hostname of the computer. imagine the headache of having to move the software to another computer with a different hostname. not fun i tell you!

[wataru]

Originally Posted by Weyland-Yutani

However this can be a part of how an OS works and OS 9 never used literal paths (on user level).

Wrong. All paths began with Macintosh HD: or whatever your hard drive was named. If you renamed your hard drive, all sorts of apps would break. I'm thinking specifically of Netscape, which would lose track of where your profile was stored.

I've never ever had a problem renaming my HD in OS X, but Netscape always gave me trouble in OS 9.

[Weyland-Yutani]

Originally Posted by wataru

Wrong. All paths began with Macintosh HD: or whatever your hard drive was named. If you renamed your hard drive, all sorts of apps would break. I'm thinking specifically of Netscape, which would lose track of where your profile was stored.

I've never ever had a problem renaming my HD in OS X, but Netscape always gave me trouble in OS 9.

Wrong. OS 9 never used literal paths. Netscape is not OS 9.

cheers

W-Y

[CharlesS]

To sum up what others have already said:

Using a hard path usually means a UNIX app or a Cocoa app, and both reference the boot disk as '/', meaning that the name of the disk does not matter.

With Carbon apps, most will be using FSRefs or aliases, neither of which rely solely on the path, so the name of the disk shouldn't matter.

Conclusion: You should be okay.

[slugslugslug]

Originally Posted by Weyland-Yutani

Wrong. OS 9 never used literal paths. Netscape is not OS 9.

cheers

W-Y

Well, no it's not like OS 9 made apps use literal paths, but some of them did. The point is not that OS 9 is awful, but that back then there were quite a few apps that broke when you changed the hard drive name (I remember this being a problem with some version of MS Word).

It's interesting to note that Netscape was a very cross-platform app. It kinda makes sense that something like that would slip by people maintaining several similar codebases.. But IANAD..

[macintologist]

If '/' is my Macintosh HD, then how do UNIX apps call up my external Firewire drive?

[CharlesS]

Originally Posted by macintologist

If '/' is my Macintosh HD, then how do UNIX apps call up my external Firewire drive?

Most disks other than your boot disk are mounted in /Volumes. You can see exactly where all your disks are mounted by typing "df" in the Terminal.

And to answer your question, a UNIX app could find the mount point of a particular disk using an API such as statfs() or getfsstat().

[Big Mac]

I renamed my internal hard drive and time stood still for five seconds! It actually caused a disruption in the time space continuum in which I was the only animated object on the planet. Seriously.

In reality, renaming your drives is a fundamental part of the Macintosh user experience. Some people give them rather wacky names, in fact. In OS 9 I never came across an application that used the HD name in a hard path, and I can't honestly recall any app that used hard paths at all. Early on in OS X's existence a number of apps, including some of Apple's own, used relative paths to associated files, and some continue the practice. Yet, I cannot remember having a problem with a true hard path in any graphical OS X application, ever. I was unaware of their use in Cocoa applications, but I believe Charles when he says they do.

[Chuckit]

Originally Posted by Big Mac

I was unaware of their use in Cocoa applications, but I believe Charles when he says they do.

Cocoa unfortunately does not have a concept of file references or aliases like Carbon does. Almost all of the file APIs expect and return literal path strings (or URLs, which are basically the same thing). It's worth noting, though, that the Cocoa frameworks do use FSRefs and aliases internally for some things, so it's still a step above your average CLI program.

[CharlesS]

Originally Posted by Chuckit

Cocoa unfortunately does not have a concept of file references or aliases like Carbon does. Almost all of the file APIs expect and return literal path strings (or URLs, which are basically the same thing). It's worth noting, though, that the Cocoa frameworks do use FSRefs and aliases internally for some things, so it's still a step above your average CLI program.

This is true - NSDocument uses FSRefs internally (or something similar - at any rate, an NSDocument-based app is able to track an open document when you move it).

There also exist third-party wrappers that allow you to use FSRefs and aliases easily in Cocoa apps. I believe one of them is BDAlias, but since I ended up making my own for my own purposes (that's right, Pacifist and BootCD use FSRefs for lots of stuff. Yay!), I'm not too familiar with the third-party ones.

[Weyland-Yutani]

Originally Posted by slugslugslug

Well, no it's not like OS 9 made apps use literal paths, but some of them did.

Then we agree

In OS X there is an annoying tendency of sometimes using literal paths. The first example that comes to my mind is the Software Update function where it will not update a piece of software if that is not found in the predetermined path. Admittably that is borderline "OS" related, but there is more.

For instance aliases made on a hard drive that points to /Applications/ on that drive will point to /Applications/ on a local drive if opened remotely - not to the correct folder.

However this is changing and I expect this to be eradicated by the next major revisions.

cheers

W-Y

[Millennium]

Actually, this shouldn't happen. The boot drive is always referred to in the filesystem as / by links and such; the name of the hard drive is never used. There's an alias to it in /Volumes/<drivename>, but for the boot drive that's little more than a convenience thing. You might run into some trouble if you were to start booting from a different drive, but just renaming the hard drive shouldn't give you any trouble. I've done it before without any problems.

[ghporter]

Millennium, isn't the name of a drive just an attribute, rather than something fundamental like the mount point? While Windows sees a volume name as something important, *nix OSs don't because they rely on mount points (the pseudo-physical location a drive is connected to the system) for identifying hardware, so shouldn't a drive name be on the same level as any other descriptor? Or am I making this more complex than it needs to be?

[Chuckit]

Originally Posted by ghporter

Millennium, isn't the name of a drive just an attribute, rather than something fundamental like the mount point? While Windows sees a volume name as something important, *nix OSs don't because they rely on mount points (the pseudo-physical location a drive is connected to the system) for identifying hardware, so shouldn't a drive name be on the same level as any other descriptor? Or am I making this more complex than it needs to be?

For non-boot drives in OS X, the drive name is relevant to the path because the automounter mounts them under /Volumes/<drivename>.

[Millennium]

Originally Posted by ghporter

Millennium, isn't the name of a drive just an attribute, rather than something fundamental like the mount point?

The drive name would be just an attribute, except for one thing: OSX uses the drive's name to create the mount point. By default, all drives except the boot drive are mounted in /Volumes/(name), and the boot drive has an alias there too. If the drives were mounted using some other kind of unique identifier, then there would be no problem, but that's not how Apple does it.

This is still better than the Public Beta, where all drives were mounted right under the root. Although it gave a slightly more consistent feel between the Terminal and the Desktop, it caused a lot of problems when someone had a drive named, for example, "Applications". This turned out to be surprisingly common, and it's why they started using the /Volumes directory.

[Catfish_Man]

Originally Posted by CharlesS

This is true - NSDocument uses FSRefs internally (or something similar - at any rate, an NSDocument-based app is able to track an open document when you move it).

There also exist third-party wrappers that allow you to use FSRefs and aliases easily in Cocoa apps. I believe one of them is BDAlias, but since I ended up making my own for my own purposes (that's right, Pacifist and BootCD use FSRefs for lots of stuff. Yay!), I'm not too familiar with the third-party ones.

This is, imo, one of the most retarded parts of the entire Cocoa API. I mean, they're trying to get us to switch to NSURL now, which sorta makes sense, but WHY NOT NSFileSpecifier or something, that nicely wraps up the strengths of each of the various methods!? There's already a class for it (NSFileLocater), it's just not public.

[Hal Itosis]

Originally Posted by wataru

Wrong. All paths began with Macintosh HD: or whatever your hard drive was named. If you renamed your hard drive, all sorts of apps would break. I'm thinking specifically of Netscape, which would lose track of where your profile was stored. I've never ever had a problem renaming my HD in OS X, but Netscape always gave me trouble in OS 9.

If that's true, then Netscape was dumb.

As one who tinkered with AppleScript in OS 9, it was fairly common
-- whenever full paths were necessary -- to do something like this...

set HDName to (name of startup disk) as string

and from that point on, the variable HDName was all that was needed,
to build a path to some file or folder.

[ghporter]

Originally Posted by Chuckit

For non-boot drives in OS X, the drive name is relevant to the path because the automounter mounts them under /Volumes/<drivename>.

Originally Posted by Millennium

The drive name would be just an attribute, except for one thing: OSX uses the drive's name to create the mount point. By default, all drives except the boot drive are mounted in /Volumes/(name), and the boot drive has an alias there too. If the drives were mounted using some other kind of unique identifier, then there would be no problem, but that's not how Apple does it.

Ahhhh. That makes a lot of sense now. Instead of tacking on some "volume serial number" or other left field identifier, the OS uses what the user has named the drive (or left the default name). I can see how this would be cause for concern. I haven't messed with changing any drive names, and frankly our iBook is still doing fine with its 30GB drive so there's only the one drive to wonder about, thus no experience.

[CharlesS]

Originally Posted by Hal Itosis

If that's true, then Netscape was dumb.

As one who tinkered with AppleScript in OS 9, it was fairly common
-- whenever full paths were necessary -- to do something like this...

set HDName to (name of startup disk) as string

and from that point on, the variable HDName was all that was needed,
to build a path to some file or folder.

It's not even that complicated. Since Netscape stored its profiles in the Preferences folder, all they had to do was using FindFolder() to get the path to the active Preferences folder. Additional benefits to doing this would be that it would still find the Preferences folder if someone had moved or renamed the System Folder (remember, that was legal in OS 9), and also in the Multiple Users implementation and later OS X, where the Preferences folder got moved to the user's home folder instead of in the System Folder, FIndFolder() would get you the correct folder just the same.