Determine if a network share exists before mounting - objective-c

I'm working on a tool to automatically mount network volumes based on what wireless network the user is connected to. Mounting the volume is easy:
NSURL *volumeURL = /* The URL to the network volume */
// Attempt to mount the volume
FSVolumeRefNum volumeRefNum;
OSStatus error = FSMountServerVolumeSync((CFURLRef)volumeURL, NULL, NULL, NULL, &volumeRefNum, 0L);
However, if there is no network share at volumeURL (if someone turned off or removed a network hard drive, for example), Finder pops up an error message explaining this fact. My goal is for this not to happen — I'd like to attempt to mount the volume, but fail silently if mounting fails.
Does anyone have any tips on how to do this? Ideally, I'd like to find a way to check if the share exists before attempting to mount it (so as to avoid unnecessary work). If that's not possible, some way to tell the Finder not to display its error message would work as well.

This answer uses Private Frameworks. As naixn points out in the comments, this means it could break even on a dot release.
There is no way to do this using only public API (that I can find after a couple of hours of searching/disassembling).
This code will access the URL and not display any UI elements pass or fail. This includes not only errors, but authentication dialogs, selection dialogs, etc.
Also, it's not Finder displaying those messages, but NetAuthApp from CoreServices. The function being called here (netfs_MountURLWithAuthenticationSync) is called directly from the function in the question (FSMountServerVolumeSync). Calling it at this level lets us pass the kSuppressAllUI flag.
On success, rc is 0 and mountpoints contains a list of NSStrings of the mounted directories.
//
// compile with:
//
// gcc -o test test.m -framework NetFS -framework Foundation
include <inttypes.h>
#include <Foundation/Foundation.h>
// Calls to FSMountServerVolumeSync result in kSoftMount being set
// kSuppressAllUI was found to exist here:
// http://www.opensource.apple.com/source/autofs/autofs-109.8/mount_url/mount_url.c
// its value was found by trial and error
const uint32_t kSoftMount = 0x10000;
const uint32_t kSuppressAllUI = 0x00100;
int main(int argc, char** argv)
{
NSAutoreleasePool* pool = [[NSAutoreleasePool alloc] init];
NSURL *volumeURL = [NSURL URLWithString:#"afp://server/path"];
NSArray* mountpoints = nil;
const uint32_t flags = kSuppressAllUI | kSoftMount;
const int rc = netfs_MountURLWithAuthenticationSync((CFURLRef)volumeURL, NULL, NULL,
NULL, flags, (CFArrayRef)&mountpoints);
NSLog(#"mountpoints: %#; status = 0x%x", mountpoints, rc);
[pool release];
}

Related

Getting Bundle Identifier for KEXT from .kext Directory Programmatically

I'm building a kernel extension and having a .kext directory for it.
From another library API, I'm using KextManager APIs to load this kext into kernel.
Everything looks fine, here is the code piece that I'm loading the kext with:
CFStringRef path = CFStringCreateWithCString(kCFAllocatorDefault, "awesome.kext", kCFStringEncodingUTF8);
CFURLRef url = CFURLCreateWithFileSystemPath(kCFAllocatorDefault, path, kCFURLPOSIXPathStyle, true);
OSReturn result = KextManagerLoadKextWithURL(url, NULL);
It works great, however I need to know my bundle identifier to have control socket connection, and maybe unload the kext with KextManagerUnloadKextWithIdentifier(kextId) API later.
So I'm aware of XXX.kext/Contents/Info.plist which contains CFBundleIdentifier key with bundle identifier but I need some way of getting it programmatically (some API?) instead of reading Info.plist file and parsing it.
I also tried to replace CFBundleIdentifier string value with something else and load into kernel, it still works fine, so it looks like Info.plist is not reliable anyway.
Is there anything related? Any suggestions? Thanks! :)
I discovered 2 useful approaches recently, both based on KextManagerCopyLoadedKextInfo API.
void handle_kext(const void* key, const void* value, void* context)
{
// OSBundlePath - CFString (this is merely a hint stored in the kernel; the kext is not guaranteed to be at this path)
CFStringRef bundle_path_key = CFStringCreateWithCString(kCFAllocatorDefault, "OSBundlePath", kCFStringEncodingUTF8);
const char* bundle_id_cstring = CFStringGetCStringPtr(key, kCFStringEncodingUTF8);
const char* bundle_path_cstring = CFStringGetCStringPtr(CFDictionaryGetValue(value, bundle_path_key, kCFStringEncodingUTF8);
// #1 Approach: Compare your 'I-Want-This-BundleID' with loaded kext path
// #2 Approach: Compare your 'I-Want-This-BundlePath' with loaded kext ID
}
void some_func()
{
CFDictionaryRef loaded_kexts = KextManagerCopyLoadedKextInfo(NULL, NULL);
CFDictionaryApplyFunction(loaded_kexts, handle_kext, NULL);
}

FTDI Communication with USB device - Objective C

I'm trying to communicate with the Enttec USB DMX Pro. Mainly receiving DMX.
They released a Visual C++ version here, but I'm a little stumped on what to do to convert to Obj-c. Enttec writes, "Talk to the PRO using FTDI library for Mac, and refer to D2XX programming guide to open and talk to the device." Any example apps for Objective-C out there? Is there an easy way to communicate with the Enttec DMX USB Pro?
I've done a significant amount of work with the FTDI chips on the Mac, so I can provide a little insight here. I've used the single-channel and dual-channel variants of their USB-serial converters, and they all behave the same way.
FTDI has both their Virtual COM Port drivers, which create a serial COM port on your system representing the serial connection attached to their chip, and their D2XX direct communication libraries. You're going to want to work with the latter, which can be downloaded from their site for various platforms.
The D2XX libraries for the Mac come in a standalone .dylib (the latest being libftd2xx.1.2.2.dylib) or a new static library they started shipping recently. Included in that package will be the appropriate header files you need (ftd2xx.h and WinTypes.h) as well.
In your Xcode project, add the .dylib as a framework to be linked in, and add the ftd2xx.h, WinTypes.h, and ftd2xx.cfg files to your project. In your Copy Bundled Frameworks build phase, make sure that libftd2xx.1.2.2.dylib and ftd2xx.cfg are present in that phase. You may also need to adjust the relative path that this library expects, in order for it to function within your app bundle, so you may need to run the following command against it at the command line:
install_name_tool -id #executable_path/../Frameworks/libftd2xx.1.2.2.dylib libftd2xx.1.2.2.dylib
Once your project is all properly configured, you'll want to import the FTDI headers:
#import "ftd2xx.h"
and start to connect to your serial devices. The example you link to in your question has a downloadable C++ sample that shows how they communicate to their device. You can bring across almost all of the C code used there and place it within your Objective-C application. They just look to be using the standard FTDI D2XX commands, which are described in detail within the downloadable D2XX Programmer's Guide.
This is some code that I've lifted from one of my applications, used to connect to one of these devices:
DWORD numDevs = 0;
// Grab the number of attached devices
ftdiPortStatus = FT_ListDevices(&numDevs, NULL, FT_LIST_NUMBER_ONLY);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Unable to list devices");
return;
}
// Find the device number of the electronics
for (int currentDevice = 0; currentDevice < numDevs; currentDevice++)
{
char Buffer[64];
ftdiPortStatus = FT_ListDevices((PVOID)currentDevice,Buffer,FT_LIST_BY_INDEX|FT_OPEN_BY_DESCRIPTION);
NSString *portDescription = [NSString stringWithCString:Buffer encoding:NSASCIIStringEncoding];
if ( ([portDescription isEqualToString:#"FT232R USB UART"]) && (usbRelayPointer != NULL))
{
// Open the communication with the USB device
ftdiPortStatus = FT_OpenEx("FT232R USB UART",FT_OPEN_BY_DESCRIPTION,usbRelayPointer);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Can't open USB relay device: %d", (int)ftdiPortStatus);
return;
}
//Turn off bit bang mode
ftdiPortStatus = FT_SetBitMode(*usbRelayPointer, 0x00,0);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Can't set bit bang mode");
return;
}
// Reset the device
ftdiPortStatus = FT_ResetDevice(*usbRelayPointer);
// Purge transmit and receive buffers
ftdiPortStatus = FT_Purge(*usbRelayPointer, FT_PURGE_RX | FT_PURGE_TX);
// Set the baud rate
ftdiPortStatus = FT_SetBaudRate(*usbRelayPointer, 9600);
// 1 s timeouts on read / write
ftdiPortStatus = FT_SetTimeouts(*usbRelayPointer, 1000, 1000);
// Set to communicate at 8N1
ftdiPortStatus = FT_SetDataCharacteristics(*usbRelayPointer, FT_BITS_8, FT_STOP_BITS_1, FT_PARITY_NONE); // 8N1
// Disable hardware / software flow control
ftdiPortStatus = FT_SetFlowControl(*usbRelayPointer, FT_FLOW_NONE, 0, 0);
// Set the latency of the receive buffer way down (2 ms) to facilitate speedy transmission
ftdiPortStatus = FT_SetLatencyTimer(*usbRelayPointer,2);
if (ftdiPortStatus != FT_OK)
{
NSLog(#"Electronics error: Can't set latency timer");
return;
}
}
}
Disconnection is fairly simple:
ftdiPortStatus = FT_Close(*electronicsPointer);
*electronicsPointer = 0;
if (ftdiPortStatus != FT_OK)
{
return;
}
Writing to the serial device is then pretty easy:
__block DWORD bytesWrittenOrRead;
unsigned char * dataBuffer = (unsigned char *)[command bytes];
//[command getBytes:dataBuffer];
runOnMainQueueWithoutDeadlocking(^{
ftdiPortStatus = FT_Write(electronicsCommPort, dataBuffer, (DWORD)[command length], &bytesWrittenOrRead);
});
if((bytesWrittenOrRead < [command length]) || (ftdiPortStatus != FT_OK))
{
NSLog(#"Bytes written: %d, should be:%d, error: %d", bytesWrittenOrRead, (unsigned int)[command length], ftdiPortStatus);
return NO;
}
(command is an NSData instance, and runOnMainQueueWithoutDeadlocking() is merely a convenience function I use to guarantee execution of a block on the main queue).
You can read raw bytes from the serial interface using something like the following:
NSData *response = nil;
DWORD numberOfCharactersToRead = size;
__block DWORD bytesWrittenOrRead;
__block unsigned char *serialCommunicationBuffer = malloc(numberOfCharactersToRead);
runOnMainQueueWithoutDeadlocking(^{
ftdiPortStatus = FT_Read(electronicsCommPort, serialCommunicationBuffer, (DWORD)numberOfCharactersToRead, &bytesWrittenOrRead);
});
if ((bytesWrittenOrRead < numberOfCharactersToRead) || (ftdiPortStatus != FT_OK))
{
free(serialCommunicationBuffer);
return nil;
}
response = [[NSData alloc] initWithBytes:serialCommunicationBuffer length:numberOfCharactersToRead];
free(serialCommunicationBuffer);
At the end of the above, response will be an NSData instance containing the bytes you've read from the port.
Additionally, I'd suggest that you should always access the FTDI device from the main thread. Even though they say they support multithreaded access, I've found that any kind of non-main-thread access (even guaranteed exclusive accesses from a single thread) cause intermittent crashes on the Mac.
Beyond the cases I've described above, you can consult the D2XX programming guide for the other functions FTDI provides in their C library. Again, you should just need to move over the appropriate code from the samples that have been provided to you by your device manufacturer.
I was running into a similar issue (trying to write to the EntTec Open DMX using Objective-C), without any success. After following #Brad's great answer, I realized that you also need to toggle the BREAK state each time you send a DMX packet.
Here's an example of my loop in some testing code that sends packets with a 20 millisecond delay between frames.
while (1) {
FT_SetBreakOn(usbRelayPointer);
FT_SetBreakOff(usbRelayPointer);
ftdiPortStatus = FT_Write(usbRelayPointer, startCode, 1, &bytesWrittenOrRead);
ftdiPortStatus = FT_Write(usbRelayPointer, dataBuffer, (DWORD)[command length], &bytesWrittenOrRead);
usleep(20000);
}
Hope this helps someone else out there!

File copy with progress indicator [duplicate]

FSCopyObjectAsync is Deprecated in OS X v10.8, Now how to display progress indictor for file copy operation.
My answer assumes you're talking about showing the progress of a single file being copied.
Yes, "FSCopyObjectAsync" been deprecated but it's not gone yet.
And as you have discovered, Apple has not yet provided a useful replacement for the functionality that will eventually be removed. I suspect (but do not know for certain) that when the new functionality comes in, perhaps for 10.9, it will be delivered in the "NSFileManagerDelegate" protocol for delegates to make use of.
To make certain of that, Apple needs to be aware there are lots of developers need this. File a bug report at http://bugreporter.apple.com -- it'll likely be closed as a duplicate, but every vote counts.
copyfile(3) is alternative for FSCopyObjectAsync. Here is example of copyfile(3) with Progress Callback.
I created an open source project addressing this issue, I wrapped copy file(3) on a NSOperation and created a gui for it, please check it out and maybe contribute to make it better.
https://github.com/larod/FileCopyDemo
Coping files with progressIndicator in C
#define BUFSIZE (64*1024)
void *thread_proc(void *arg);
{
//outPath & inPatn an NSString paths
char buffer[BUFSIZE];
const char * outputFile = [outPath UTF8String];
const char * inputFile = [inPath UTF8String];
int in = open(inputFile, O_RDONLY);
int out = open(outputFile, O_WRONLY | O_CREAT | O_TRUNC);
vvolatile off_t progress;
progress = 0;
ssize_t bytes_read;
double fileSize = 0;
NSNumber * theSize;
if ([inPath getResourceValue:&theSize forKey:NSURLFileSizeKey error:nil])
fileSize = [theSize doubleValue];
[progressIndicator setMaxValue:fileSize];
while((bytes_read = read(in, buffer, BUFSIZE)) > 0)
{
write(out, buffer, BUFSIZE);
progress += bytes_read;
[progressIndicator setDoubleValue:progress];
}
// copy is done, or an error occurred
close(in);
close(out);
}

C Callback in Objective-C (IOKIT)

I am trying to write some code that interacts with an USB device in Objective C, and I got stuck on setting the callback function for incoming reports. In my case it's an IOKIT function but I think the problem is more general as I (apparently) don't know how to correctly set a C callback function in Objective-C. I've got a Class "USBController" that handles the io functions
USBController.m:
#include <CoreFoundation/CoreFoundation.h>
#include <Carbon/Carbon.h>
#include <IOKit/hid/IOHIDLib.h>
#import "USBController.h"
static void Handle_IOHIDDeviceIOHIDReportCallback(
void * inContext, // context from IOHIDDeviceRegisterInputReportCallback
IOReturn inResult, // completion result for the input report operation
void * inSender, // IOHIDDeviceRef of the device this report is from
IOHIDReportType inType, // the report type
uint32_t inReportID, // the report ID
uint8_t * inReport, // pointer to the report data
CFIndex InReportLength) // the actual size of the input report
{
printf("hello"); //just to see if the function is called
}
#implementation USBController
- (void)ConnectToDevice {
...
IOHIDDeviceRegisterInputReportCallback(tIOHIDDeviceRefs[0], report, reportSize,
Handle_IOHIDDeviceIOHIDReportCallback,(void*)self);
...
}
...
#end
All the functions are also declared in the header file.
I think I did pretty much the same as what I've found here, but it doesn't work. The project compiles nicely and everything works up till the moment there is input and the callback function is to be called. Then I get an "EXC_BAD_ACCESS" error. The first three arguments of the function are correct. I'm not so sure about the context..
What did I do wrong?
I am not sure at all that your EXEC_BAD_ACCESS depends on your callback. Indeed, if you say that it is called (I suppose you see the log) and since it only logs a message, there should be no problem with this.
EXEC_BAD_ACCESS is caused by an attempt to access an already deallocated object. You can get more information in two ways:
execute the program in debug mode, so when it crashes you will be able to see the stack content;
activate NSZombies or run the program using the performance tool Zombies; this will tell you exactly which object was accessed after its deallocation.
I know how to fix this. When calling this:
IOHIDDeviceRegisterInputReportCallback(tIOHIDDeviceRefs[0], report, reportSize,
Handle_IOHIDDeviceIOHIDReportCallback,(void*)self);
You don't include the code for the creation/type of the value called report. However the method name "Handle_IOHIDDeviceIOHIDReportCallback" comes from an Apple document where there is an error in the creation of the report value. https://developer.apple.com/library/archive/technotes/tn2187/_index.html
CFIndex reportSize = 64;
uint8_t report = malloc( reportSize ); // <---- WRONG
IOHIDDeviceRegisterInputReportCallback( deviceRef,
report,
reportSize,
Handle_IOHIDDeviceIOHIDReportCallback,
context );
Instead do this:
uint8_t *report = (uint8_t *)malloc(reportSize);

Finder Scripting Bridge to Shutdown

I tried to use Application Scripting Bridge to send my Mac to sleep.
The code look like the following:
#import "Finder.h"
FinderApplication *Finder = [SBApplication applicationWithBundleIdentifier:#"com.apple.finder"];
[Finder sleep];
But it doesn't work. Any ideas why it doesn't work? No compiling errors or warnings, but it doesn't work…
As I posted in this answer, I've been using the following code for over 8 years without issues:
MDRestartShutdownLogout.h:
#import <CoreServices/CoreServices.h>
/*
* kAERestart will cause system to restart
* kAEShutDown will cause system to shutdown
* kAEReallyLogout will cause system to logout
* kAESleep will cause system to sleep
*/
extern OSStatus MDSendAppleEventToSystemProcess(AEEventID eventToSend);
MDRestartShutdownLogout.m:
#import "MDRestartShutdownLogout.h"
OSStatus MDSendAppleEventToSystemProcess(AEEventID eventToSendID) {
AEAddressDesc targetDesc;
static const ProcessSerialNumber kPSNOfSystemProcess = {0, kSystemProcess };
AppleEvent eventReply = {typeNull, NULL};
AppleEvent eventToSend = {typeNull, NULL};
OSStatus status = AECreateDesc(typeProcessSerialNumber,
&kPSNOfSystemProcess, sizeof(kPSNOfSystemProcess), &targetDesc);
if (status != noErr) return status;
status = AECreateAppleEvent(kCoreEventClass, eventToSendID,
&targetDesc, kAutoGenerateReturnID, kAnyTransactionID, &eventToSend);
AEDisposeDesc(&targetDesc);
if (status != noErr) return status;
status = AESendMessage(&eventToSend, &eventReply,
kAENormalPriority, kAEDefaultTimeout);
AEDisposeDesc(&eventToSend);
if (status != noErr) return status;
AEDisposeDesc(&eventReply);
return status;
}
Note that the above code is based on the code from Technical Q&A QA1134, but mine is re-worked to use AESendMessage() rather than AESend(). AESend() is in HIToolbox.framework, which is in Carbon.framework and is therefore unavailable to 64-bit apps. (AESendMessage() is part of the AE.framework in CoreServices).
If Scripting Bridge isn't sufficient to do something non-application specific, like shutting down the Mac, then you have the luxury of moving to other frameworks that Applescript (and by extension Scripting Bridge) doesn't have direct access to. For shutting down the Mac, see Core Services: Technical Q&A QA1134: Programmatically causing restart, shutdown and/or logout