macOS Getting the current working Volume name?

[kuroyume0161]

I'm working in a plugin SDK which has no means to get the Volume name of the volume in which the plugin is running - for file paths on the same volume it returns relative paths (/Applications/...). I need the volume name for fopen()/gzopen() for zlib support (/Volumes/VOLUMENAME/...). This is C++, XCode, PPC+UB.

How would I go about getting the volume name of the volume in question? As stated, nothing in the SDK will return the volume name of the starting volume when the other reference is on the same volume.

Thank you very much!

Robert

 

[kainjow]

NSFileManager's displayNameAtPath: may be of help.

 

[kuroyume0161]

That only returns an 'NSString' representation of the path described - not much else of interest there.

I have no volume to start with. The path is something like this:

"/Application/Maxon/Cinema 4D R10/..."

I need this bit (which is not there!!!):

"Macintosh HD/Application/Maxon/Cinema 4D R10/..."

That part is the mystery. If the file reference is to another volume, then "/Volumes/OtherVolume/...." is prepended to the file path. If the file reference is on the same volume (and can you tell me the name of that volume?), the reference is void, bereft, without, and absent a volume: "<NO VOLUME>/Folder/Folder/...". Figure that one out?

I ask for an answer, please. Remember this is a PLUGIN SDK. I'm not writing a Cocoa/Carbon/BSD/Darwin APPLICATION. I'm writing a C++ dylib that is run in another application. I'll include the appropriate framework if necessary, but I want a source code solution - not a hint to a possibility to a maybe...

P.S.: There is no MacOS specific file access here - it is plugin SDK access. So I need to turn a POSIX file path into the appropriate SDK path (an SDK Filename class which needs to end up like "/Volumes/volume_name/folder/folder/.../file.ext"). I know of no methods that takes a relative path and returns this (not FSRef, FSSpec, etc.). Apple has abandoned developers of plugins for applications. They are deaf to the problems involved. If I wanted to write a sub-structure just for these MacOSX idiosyncracies, I'd need Apple send me money to cover my development costs (or charge twice as much to Mac users) - bullocks!!!

As I mentioned on the SDK forum - support POSIX (oh, in conjunction with and not in spite of) with the new file path specifications. Breaking fopen() is a cardinal sin. You get the same punishment as murderers and evil people like Hitler... ;P BTW, it's fopen() and GZOPEN() for zlib-compressed file support - there are no alternatives.

Thanks,

Robert

 

[kainjow]

Ok well it seems like you're confusing your terminology. SDK is a generic term, not referring to any kind of API or platform or language.

Now, from my understanding, you want to get the name of the volume that a path resides on? If so, here is some code that will do just that in C. Just link against Carbon.framework. I'm not sure why you'd want this, unless you were working with HFS paths (e.g. Macintosh HD:Users:Bobesktop).

Also, Apple hasn't left developers behind... not sure where you're getting that from. Maybe if you can describe your problem a little more clearly we can help you more.

#include <Carbon/Carbon.h>

void volumeNameForPath(char *path, char **volname)
{
	CFStringRef pathRef = CFStringCreateWithCString(NULL, path, CFStringGetSystemEncoding());
	CFURLRef url = CFURLCreateWithString(NULL, pathRef, NULL);
	FSRef bundleRef;
	FSCatalogInfo info;
	HFSUniStr255 volName;

	if (url)
	{
		if (CFURLGetFSRef(url, &bundleRef))
		{
			if (FSGetCatalogInfo(&bundleRef, kFSCatInfoVolume, &info, NULL, NULL, NULL) == noErr)
			{
				if ( FSGetVolumeInfo ( info.volume, 0, NULL, kFSVolInfoNone, NULL, &volName, NULL) == noErr)
				{
					CFStringRef stringRef = FSCreateStringFromHFSUniStr(NULL, &volName);
					if (stringRef)
					{
						*volname = NewPtr(CFStringGetLength(stringRef)+1);
						CFStringGetCString(stringRef, *volname, CFStringGetLength(stringRef)+1, kCFStringEncodingMacRoman);
						CFRelease(stringRef);
					}
				}
			}
		}

		CFRelease(url);
	}
}

int main()
{
	char *volname = NULL;
	volumeNameForPath("/Applications/", &volname);
	printf("volname: %s\n", volname);
	DisposePtr(volname);

	return 0;
}

Above code prints out "Macintosh HD" on my comp. Or you can pass in any "/Volumes/blah/..." path and it will return the name of that volume.

 

[kuroyume0161]

Nope. I said "plugin SDK". This is an SDK for an application to create 'plugins' that run in that application - the language is C++, the result is a lib (.cdl, .xdl, .dylib).

I wasn't talking about Mac SDKs or XCode plugins. This "plugin SDK" is for an application that runs on Windows, Windows 64-bit, MacOS Classic, and MacOSX Universal Binary - and, um, I support all of them. No confusion in terminology from this "professional" developer, thank ya very much. ;P

Will your code get "Macintosh HD" when the input is "/Applications/...." without the "Macintosh HD" part already there! It looks like it might - so I must thank you for that. What frameworks are needed - just Carbon?

ETA: I'll just state that I am within the confines of the SDK. I can't open files ubiquitously (across systems) if I have to resort to MacOSX-specifics as an exception. That's why this SDK has classes like BrowseFiles (for getting files in a directory), Filename (for specifying file paths/names), and BaseFile (for reading/writing files) that are platform-independent. The problem is that MacOSX+XCode break the POSIX paths that work everywhere else (we're talking Windows 32-bit, Windows 64-bit, and MacOS Classic here). Even they are resorting to the MacOSX paths for these classes. But since I also need zlib file support, this won't work. The MacOSX libz.dylib uses the same ole' gzopen() which (fyi) is only an extension of fopen() which (fyi) requires a POSIX path (doh!). Their previous UB SDK still utilized the POSIX paths, but the new release/version SDK utilizes the MacOSX paths "/Applications/..." (relative volume) and "/Volumes/MyOtherHD/Applications/..." (absolute). In the former case, fopen/gzopen spew. They either need a working directory set (not going there) or a full path. And the latter requires the volume name. So, let me try your code and I'll quickly give you many thanks if it works!

Robert

 

[kainjow]

Will your code get "Macintosh HD" when the input is "/Applications/...." without the "Macintosh HD" part already there! It looks like it might - so I must thank you for that. What frameworks are needed - just Carbon?

Yes, pass it any path like "/" or "/Users" or "/Volumes/something/asdf" and it will work. And yes, you only need to link against Carbon.framework.

Beware though, that FSCreateStringFromHFSUniStr() works on 10.4 and later only. However, there is another way of doing it that works on previous systems - that's for you to figure out

 

[kuroyume0161]

Yes, professional.

I only came here after spending days (yay, weeks) trying to find answers to this online. Most of the Google search responses are about 'fixes to my app for this situation - with no explanation' or 'setting XCode relative/absolute paths' or ... anything but this specific scenario. Yep, I tried searching every permutation with "MacOSX" "XCode" "Volume" "Volume name" "path" "relative path" "full path" "Posix"......... Some of you guys ought to learn the phrase "open" for development support.

I still can't believe that Apple uses 'newsgroups' for most of their developer support (there is this thing called 'the world wide web' and it includes cushy forums - wow). I don't use newsgroups. And searches at Apple's site are horrific. Can you point to the solution to this explained there?

I'll admit that my MacOS development experience is limited (I'm spoiled on Amiga, Linux, DOS, and Windows), but that doesn't excuse the situation. If you need to use POSIX paths (and there is no way that I know of to avoid this with gzopen(), you are left out in the cold - even if the solution is there in many places with much eye-strain involved). I don't have the resources (me, myself, und I) to do R&D over months to resolve a single issue on a single version - there is much more work of importance beyond that!

I should only be needing 10.3.9 or later (since the SDK docs are not even available yet - see my plight - and I haven't even received my registered version of the application yet - using demo - but still users are clamoring for the support as they receive theirs - I'm not certain of the minimum MacOS system requirements).

I apologize for not having inexhaustible time and resources to read the thousands and thousands of pages of Apple developer documentation (at least) and knowing it all. I try to avoid the platform-dependent stuff at all costs (that's why I skipped from C to Java - C++ was and is ridiculous, but I have no choice in this situation, I must remiss).

Nonetheless, we've exchanged insults (and I meant none towards you!). And I very much appreciate your help! Most of my angst is against Apple's poor developer support. If you can give information that would 'remove the scales from my eyes' in this regard, all the more praise to you!

Thank you very much,

Robert

 

[kainjow]

I figured out how to do it by combining a few things I found together. Since I do Cocoa stuff almost exclusively, I search the Cocoa mailing list archives very frequently, which also has good general Carbon advice also. Check them out at http://lists.apple.com

Can I ask how you're doing what you're doing for Windows and why it doesn't work for Mac OS X?

Also I though "POSIX" referred to paths like "/Blah/blah"? Windows, if anything, is not very standard at all (or at least not until recently). And if you have experience in Linux, then Mac OS X is not very different at all since it's based on Unix.

 

[kuroyume0161]

I figured out how to do it by combining a few things I found together. Since I do Cocoa stuff almost exclusively, I search the Cocoa mailing list archives very frequently, which also has good general Carbon advice also. Check them out at http://lists.apple.com

Can I ask how you're doing what you're doing for Windows and why it doesn't work for Mac OS X?

Also I though "POSIX" referred to paths like "/Blah/blah"? Windows, if anything, is not very standard at all (or at least not until recently). And if you have experience in Linux, then Mac OS X is not very different at all since it's based on Unix.

Thanks for the link! Will need to immerse into that one too.

Yeah, I have not had much experience with all of this Cocoa/Carbon stuff (some Carbon, but not much). The new frameworks in XCode just make it scarier (or simpler if it clicks with you). The plugin SDK buffers much of this for platform-independence. But in the case of my plugin, there are requirements beyond the plugin SDK that require delving into the OS (zlib, for instance, is an additional lib linked in and works the same on all the other systems, but the file paths with MacOSX are proving difficult with it).

Windows still accepts POSIX-style paths (as it were) "C:\Program Files\TheApp\...". The SDK there will still respond with a full path, including volume. The previous SDK on MacOS (UB) does the same. It is only with this new SDK that they have decided to go with the other path specifications - "/Applications/..." without the volume when the reference is on the same volume. That is causing problems with the zlib support. From my readings, there are two directions to fix this - setting the current working directory (without any explanation or code - I haven't set a current working directory since DOS some ten year ago or more) or use the "/Volumes/volume_name/" prepended to the POSIX path.

This new SDK is not yet fully realized, I must add - I've complained about releasing a new application version and not providing SDK documentation to developers even after release! You'd think that they'd do it conversely - release the SDK documentation to the developers first and then release the application later. Nope.

My Linux experience is long-in-the-tooth. But I have not encountered situations in any of these other OSs like this. I can see the reasons for the aliased/non-generic-root-specific path specifications as being complimentary - it really does not help when the old POSIX paths are required. There should be direct support for these (even if begrudgringly). This is not a console app that is BSD-compliant (and therefore Unix compatible). This application runs in MacOSX as a Universal Binary application - with PPC+UB intermixed support in the plugin dylib. And I guess that is where I'm lost. Apple seems to do much splitting between these - but the reality is that sometimes you need some BSD, some Darwin, some Cocoa, some Carbon, some other stuff. This should be spelled out - and it may be in the coming years.

Again, thank you for your help! My posts are in frustration, but this is the reason I posted. It is this kind of kind support that helps development progress! I make it a point to post solutions on the 'plugin SDK' forum (this is Maxon's plugincafe for Cinema 4D plugin development) just because I hate to withold information. Some stuff is proprietary and should be protected from dispersal to public scrutiny. But when it is a general solution, it should be made available for all. And I thank you for that.

Robert

 

[gnasher729]

I'm working in a plugin SDK which has no means to get the Volume name of the volume in which the plugin is running - for file paths on the same volume it returns relative paths (/Applications/...). I need the volume name for fopen()/gzopen() for zlib support (/Volumes/VOLUMENAME/...). This is C++, XCode, PPC+UB.

How would I go about getting the volume name of the volume in question? As stated, nothing in the SDK will return the volume name of the starting volume when the other reference is on the same volume.

Thank you very much!

Robert

You might try "/", see what happens.
Otherwise, use FSGetVolumeInfo to iterate through all the volumes, get the volume names and paths for each volume, and the one that reports a path of "/" is the default volume.

 

[kuroyume0161]

You might try "/", see what happens.
Otherwise, use FSGetVolumeInfo to iterate through all the volumes, get the volume names and paths for each volume, and the one that reports a path of "/" is the default volume.

Try "/" with what? I'm getting the file paths from the SDK. If the path is on the same volume as the application, it returns "/Applications/...." My understanding is that the first '/' there represents the 'current volume'. But I need a volume name for fopen/gzopen. They definitely cannot handle that relative volume spec. Even the volume name isn't enough. It has to be "/Volumes/volume_name/Applications/..." Then it works in these.

The SDK has just added a BrowseVolumes class - I might see if this does the trick - remembering that there are no docs for this version of the SDK available to developers yet.

Users want it yesterday and I can't even get the needed documentation tomorrow! ;D

Thanks,
Robert

 

[kainjow]

"/" isn't relative. It's absolute. It's referring to the active startup drive on Mac OS X.

 

[kuroyume0161]

Agreed. But it's all relative to me.

One must remember that I've only been developing on the Mac for a couple years - and only behind the veil of the plugin SDK. Most of my experience is Amiga, MSDOS, and Windows. While doing Java for some years, there was no need to worry even about the MacOS - when Java was made available in MacOSX, the code still worked on the Mac just as it did on Windows (barring the underlying Java implementations for things like Swing etc.).

And only with R9.5 (two not very distant versions back) did the application move from CodeWarrior/Classic target to XCode/Universal Binary target (that's less than a year). Considering the scope of the changes from Apple, it could be years before this all gets clearer to me.

Not everyone is a veteran Mac developer developing on the Mac. I'm a veteran - just not a Mac veteran.

Take care and will get back with my results - other duties to perform here first before delving into the code.

Robert

 

[gnasher729]

Try "/" with what? I'm getting the file paths from the SDK. If the path is on the same volume as the application, it returns "/Applications/...." My understanding is that the first '/' there represents the 'current volume'. But I need a volume name for fopen/gzopen. They definitely cannot handle that relative volume spec. Even the volume name isn't enough. It has to be "/Volumes/volume_name/Applications/..." Then it works in these.

The SDK has just added a BrowseVolumes class - I might see if this does the trick - remembering that there are no docs for this version of the SDK available to developers yet.

Users want it yesterday and I can't even get the needed documentation tomorrow! ;D

Thanks,
Robert

I find this a bit confusing. As an example, in Terminal the command "cat /Applications/Mail.app/Contents/version.plist" will list the version.plist of the Mail application, and fopen () will open that file just fine - except that you might not have read/write privileges (reasonably likely that you don't have write privileges to modify applications).

 

[GeeYouEye]

Near as I can tell, if the behavior truly is as you describe, you should file a bug against the SDK. It shouldn't be returning "/" for the current working volume, only the startup volume. And if the current working volume always is the startup volume, then you're using fopen/gzopen incorrectly, as they will always work with /-rooted files. In fact, that's all they work with unless you've set your cwd in code.

 

[mrichmon]

I'm working in a plugin SDK which has no means to get the Volume name of the volume in which the plugin is running - for file paths on the same volume it returns relative paths (/Applications/...). I need the volume name for fopen()/gzopen() for zlib support (/Volumes/VOLUMENAME/...). This is C++, XCode, PPC+UB.

You should remember that you have no guarantee that a volume will be mounted under /Volumes. The default behavior for OS X is to mount all filesystems other than the root file system under /Volumes. However, if the user has setup an fstab file then the filesystems specified in the fstab file can be mounted anywhere.

One approach that you could use would be to parse the output from disktool to build a table of "volName" to "mount point" correspondences. You could then get the current directory and establish which mount point the current directory resides in.