User Profile

I like to find a way to identify network volumes, and whether they're run by certain servers, e.g. specifically whether they're on a Synology NAS. Reason is that Synology, while apparently supporting the Spotlight-over-SMB API, comes with a lot of bugs, requiring me to work around them when searching on those volumes with the macOS Spotlight API. I could, of course, ask the user to "configure" each mounted volume in my software, but I'd rather do this automagically, if possible, as it's less prone to user mistakes. So, my question is: Is there a way to learn a bit more about the server of a mounted network volume? E.g., if I could learn its IP address, I could try to connect to it via http protocol and then maybe get a useful response that identifies it as being from Synology. Or, alternatively, can I tell which SMB volumes are served by a Mac, so that I can at least assume that those handle Spotlight calls correctly, while I assume anything else is buggy (so far, AFAIK, Synology is the only other SMB server that supports Spotlight search). I've tried to find some data in the IORegistry, but that doesn't seem to store anything about network vols. The statfs function doesn't seem to give me anything for that either, nor do the various fcntl calls as far as I could tell. I also checked with the DA apis, e.g.: DASessionRef daSession = DASessionCreate (NULL); CFURLRef furl = CFURLCreateWithFileSystemPath(NULL, CFSTR("/Volumes/TheNAS"), kCFURLPOSIXPathStyle, true); DADiskRef daDisk = DADiskCreateFromVolumePath (NULL, daSession, furl); if (daDisk) { CFDictionaryRef daInfo = DADiskCopyDescription (daDisk); NSLog(@"%@", daInfo); } However, this only prints basic information: DAVolumeKind = smbfs; DAVolumeMountable = 1; DAVolumeName = TheNAS; DAVolumeNetwork = 1; DAVolumePath = "file:///Volumes/TheNAS/"; Where, then, does Finder's "Get Info" get the smb path from, for example?

When using the mount command on macOS, I can see mounted network servers like this: //tt@mynas.local/NAS on /Volumes/NAS (smbfs, nodev, nosuid, mounted by thomas) In this example "thomas" is my macOS user name, under which I mounted the "NAS" volume. But there's also the "tt" name before the "@" - and that's what I'm interested in getting - that's the user name known to the server, i.e. the name I logged in on the server when the connection prompt appeared. How do I get this name (tt) via macOS APIs? I can get it via "mount", but that requires parsing and is inefficient, and so I like to avoid that if possible. man mount mentions getfsent(), but in my testing it only lists internal volumes, not network volumes.

On macOS, if I mount two volumes whose name is the same, the second one gets renamed, by appending "-1" to its name. I need a method to determine the original volume name, i.e. without such a suffix. (Of course, I cannot blindly remove any "-" plus digits because the volume may actually be named like this.) I can find the original name when using the mount command in Terminal: //tt@192.168.61.121/NAS2 on /Volumes/NAS2 (smbfs, nodev, nosuid, mounted by tt) //tt@QNAS%28AFP%29._afpovertcp._tcp.local/NAS2 on /Volumes/NAS2-1 (afpfs, nodev, nosuid, mounted by tt) Here, I can tell that "/Volumes/NAS2-1" was originally named "NAS2" on the network. How do I determine the share's name without invoking such tools, but via CF or other macOS functions, with providing the path or URL of the mounted volume (such as "/Volumes/NAS2-1")?

I have received a few crash reports for my app "Find Any File" with an assertion failure as follows: assertion failure: "displayTiming != ((void *)0)" -> %lld Googling this turns up nothing, though. I wonder if someone has some insight into why this might happen, and how to prevent it. One reporting user suggests that it happens when my app shows a very long list of items in an NSTableView (>10000 elements). I have 4 reports from 3 users, and the main thread is doing something related to the table view each time, though not the same (the few other threads are all idle): Crash 1, in macOS 14.0 (23A344: Thread 0:: Dispatch queue: com.apple.main-thread 0 libobjc.A.dylib 0x182c69400 objc_msgSend + 0 1 AppKit 0x186f15400 -[CALayer(NSViewVisibleRect) NS_viewVisibleRectDidChange] + 40 2 AppKit 0x186900e10 NSViewHierarchyInvalidateVisibleRect + 276 3 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 4 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 5 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 6 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 7 AppKit 0x186900db0 NSViewHierarchyInvalidateVisibleRect + 180 8 AppKit 0x1869990e0 -[NSView translateOriginToPoint:] + 164 9 AppKit 0x186984108 -[NSClipView _immediateScrollToPoint:] + 420 10 AppKit 0x186983eb8 -[NSClipView scrollToPoint:] + 184 11 AppKit 0x186998d80 -[NSScrollView scrollClipView:toPoint:] + 84 12 AppKit 0x1869448dc -[NSClipView _scrollTo:animateScroll:flashScrollerKnobs:] + 480 13 AppKit 0x186b65b24 __62-[NSScrollingBehaviorConcurrentVBL _stopGestureScrollTracking]_block_invoke + 192 14 AppKit 0x186e6a6e8 ___NSMainRunLoopPerformBlockInModes_block_invoke + 44 15 CoreFoundation 0x18310b8c0 __CFRUNLOOP_IS_CALLING_OUT_TO_A_BLOCK__ + 28 Crash 2, in macOS 14.1.1 (23B81): Thread 0:: Dispatch queue: com.apple.main-thread 0 CoreFoundation 0x18ba401f4 DYLD-STUB$$_Block_object_assign + 0 1 libsystem_blocks.dylib 0x18b506118 _call_copy_helpers_excp + 80 2 libsystem_blocks.dylib 0x18b505c68 _Block_copy + 376 3 libdispatch.dylib 0x18b641c7c _dispatch_Block_copy + 32 4 libdispatch.dylib 0x18b658df0 _dispatch_source_set_handler + 92 5 CoreFoundation 0x18b99e1e4 __CFRunLoopCopyMode + 540 6 CoreFoundation 0x18b8b7458 CFRunLoopAddObserver + 220 7 AppKit 0x18f0a687c _PerfAddRunLoopObserver + 192 8 AppKit 0x18f87cd60 -[NSApplication(NSEventRouting) _nextEventMatchingEventMask:untilDate:inMode:dequeue:] + 368 9 AppKit 0x18f323318 -[_NSScrollingConcurrentEventMonitor startMonitoring] + 380 10 AppKit 0x18f321df8 -[NSScrollingBehaviorConcurrentVBL _scrollView:trackGestureScrollWithEvent:] + 884 11 AppKit 0x18f2e67f8 -[NSScrollingBehaviorConcurrentVBL scrollView:scrollWheelWithEvent:] + 512 12 AppKit 0x18f241770 forwardMethod + 252 13 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 14 AppKit 0x18f241770 forwardMethod + 252 15 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 16 AppKit 0x18f241770 forwardMethod + 252 17 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 18 AppKit 0x18f241770 forwardMethod + 252 19 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 20 AppKit 0x18fc45880 -[NSCollectionView scrollWheel:] + 180 21 AppKit 0x18f241770 forwardMethod + 252 22 AppKit 0x18f241770 forwardMethod + 252 23 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 24 AppKit 0x18f241770 forwardMethod + 252 25 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 26 AppKit 0x18f241770 forwardMethod + 252 27 AppKit 0x18f2e62a0 -[NSView scrollWheel:] + 408 28 AppKit 0x18f1d27b0 -[NSWindow(NSEventRouting) _reallySendEvent:isDelayedEvent:] + 652 As you can see, there's no code of mine involved at the time of crash. The other (and older) reports are similar, in macOS 13.6.1 and macOS 13.1. All four happened on ARM architecture (which may not be significant due to small number of samples). Memory use of app was not critical (in one case it was about 9 GB total, in others below 4 GB). The "Binary Images" section only lists Apple libs, apart from my app's. So, there seems to be no 3rd party ext involved. I've attached a full report as well. Full report of Crash 1

TL;DR I cannot install some Apple software because a certificate appears to have expired. How do I identify the culprit? I have been using Xcode 10.1 on 10.13.6 for a many years on my MacBook Pro, and suddenly it won't launch any more because it wants to install the "additional required components", but then fails at doing so with a weird "untrusted" error message. From the log file: Xcode[12324]: Package Authoring Error: PackageInfo bundle reference found without top-level bundle definition. Bundle will be skipped: <bundle id="*"></bundle> Xcode[12324]: Package: PKLeopardPackage <id=com.apple.pkg.MobileDeviceDevelopment, version=10.3.9000000000.1.1488876279, url=file:///Applications/Xcode10.1.app/Contents/Resources/Packages/MobileDeviceDevelopment.pkg> Failed to verify with error: Error Domain=PKInstallErrorDomain Code=102 "The package “MobileDeviceDevelopment.pkg” is untrusted." UserInfo={NSLocalizedDescription=The package “MobileDeviceDevelopment.pkg” is untrusted., NSURL=MobileDeviceDevelopment.pkg -- file:///Applications/Xcode10.1.app/Contents/Resources/Packages/, PKInstallPackageIdentifier=com.apple.pkg.MobileDeviceDevelopment, NSUnderlyingError=0x7f8240512710 {Error Domain=NSOSStatusErrorDomain Code=-2147409654 "CSSMERR_TP_CERT_EXPIRED" UserInfo={SecTrustResult=5, PKTrustLevel=PKTrustLevelExpiredCertificate, NSLocalizedFailureReason=CSSMERR_TP_CERT_EXPIRED}}} Everything else works fine on the system. All I changed recently, before this started happening, was to re-install 10.13.6 fresh, and then restore from a recent Time Machine backup, all in order to fix an iCloud issue that seemed to be related to SSL trust issues when contacting the iCloud sync server, but was fixed with this re-install. I've even re-downloaded the Xcode10.1.xip from Apple, but that makes no differences, it's not Xcode that's broken. The log suggests that a cert has expired, but which one would that be? I have looked at the Certificates in Keychain Access, but none of the ones that appear to be related to Apple are expired as far as I can tell. Maybe one is missing, but which? Any ideas how to analyse or fix this? (I need Xcode 10.1 because the macOS apps I make need to remain backward compatible with 10.11 and up, and I'm often debugging on High Sierra for that purpose. Besides, the same Xcode 10.1 works fine on two other Macs running 10.13.6.)

My macOS app reads the crashlog files directly and submits them to my server for analysis if the user allows it. Which means I get to see the original .ips files generated on Monterey. Now, these files appear to contain two JSON-formated records, the first detailing the app's properties. Here's a reformatted example of that as reported for my own app: { "app_name":"Find Any File", "timestamp":"2022-01-02 10:12:36.00 -0500", "app_version":"", "slice_uuid":"a15335de-4432-3b53-bcdf-381424a7a330", "build_version":"", "platform":1, "share_with_app_devs":0, "is_first_party":1, "bug_type":"309", "os_version":"macOS 12.1 (21C52)", "incident_id":"132818BA-3DBA-4B15-86CE-307BE961E7DC", "name":"Find Any File" } The problem for me here is that sometimes, like in this example, both the app_version and the build_version values are empty. That makes it difficult for me to figure out which version of my app caused the crash. I have 11 .ips crash reports, and when I compare the ones with valid version information against those missing them, the only consistency I find is that the value for is_first_party is 0 whenever I get valid versions, and 1 whenever I get empty values. Can anyone explain why this happens and how I can make this work in all cases? Note: One other developer (P.N.L.) has confirmed my findings, seeing empty versions as well, occosionally, and also directly related to the is_first_party value. (I've also asked this on SO,, but it's not a good fit there)