smb big sur

Thanks for your answer. Our app supports macOS 10.10 onwards, while the file provider is from macOS 11.0, so any solution is there for an older OS version without using ES or KAUTH framework. Historically, file sync services basically worked in one of three ways: Use Kauth to detect the open() call until the file was downloaded. This had the advantage of being relatively easy and the disadvantage of requiring a KEXT and using kauth. Note that the ES auth timeout means that it does NOT work for this use case and, yes, that's intentional. Use a VFS driver, typically using FUSE. This is marginally safer than #1 (since the file system is self-isolated) but quite complex (though FUSE helps) and requires a KEXT. Use a loopback SMB server. An SMB server is run on the machine which the machine mounts. The SMB server then handles I/O requests using a mix of its own local file cache and downloading data from the network. Looking at those architectures, I have a comment here: Working on an app

I need to use Bonjour because a big selling point of the app im working on is that N devices will be able to discover and connect to each other while offline (ie no wifi network, ie out in the middle of no where). The devices only need to have their wifi toggle on.

A housekeeping note — here is a link to a related thread Caleb started on a different slice of the problem, for anyone who may come to this in the future. I reread what you originally wrote, and it sounds like you had a reason to pull out this web bundle build into the aggregate target. Is there a reason where that couldn't be a script in the main app target that I'm not seeing? It seems like the file level input and output analysis of this step in the main app build phase would be enough. The one downside I see is that if the script does need to run in full, that could potentially be a place where you don't get a lot of concurrently running build tasks doing other things, and thus takes up more wall clock time than is ideal, but also maybe isn't that different from the pre-build script you started with. Another idea would be to question why this script needs to run via an Xcode build at all. If the source files don't change often, could other techniques like a git commit hook targeting the source file paths

Thanks for the replay. I did not create a feedback report yet but will create one. For now we moved away from relationships as this was having a big performance impact with our quite large data set. Instead our entities only store IDs of related entities. This prevents any loading of all the related entities, but adds a bit of manual work to handle the lazy loading.

The app is only doing some background tasks. Once everything is set up, the user usually do not have to check the UI. Is there some special reason you structured it this way? Not especially, it is more a legacy thing. Originally, everything was in 1 executable, but it was then split into 2 to improve responsiveness of the UI. So the main process in more the engine process while the helper process manage the UI. We have a big overhaul planned where we will probably stop using Qt and use AppKit instead for the macOS part. We should revise the structure while doing it. If you have any tips or guidelines, I'll gladly take them :) And, in the meantime, as a workaround, I will move the management of the menu bar icon into the main process.

Should we file a separate bug report, or extend FB16131472 with iPadOS 18.6 info? Sorry, I missed that in the previous posts. Please update the existing bug. Our app utilizes AppleArchive to back up and restore data via UIDocumentPickerViewController. We implemented the variant of UIDocumentPickerViewController that copies the archive file because we had the impression Apple recommended (or required) this variant when reading archives from an external drive. To be honest, I can't think of any reason it would really be THAT different. Practically speaking, the ability to read a file is the same as being able to copy it (since a copy is just reading from a source and writing to a destination). Similarly, while it's possible for two different engines to produce different results*, we've been consolidating our copy engines such that using asCopy SHOULD give you the same result as copyItems. Finally, the kinds of edge cases that copying” is so messy are exactly why formats like AppleArchive or zip exist. That is,

Wasn't that barely two days ago? The dot com glory days of instant enrolments is over. You should be prepared to wait weeks to months for most business-related issues. Dun & Bradstreet is actually one of the best companies in this respect. I got my DUNS number in 2015 and it took a week. I recently changed my address with them and that took about a week. Their estimate for completing the change was about a week. And they even send me a confirmation saying (in big red text) Your updated DUNS number will be eligible for Apple Registration after 24-48 hours. So really top-notch. Kudos to Dun & Bradstreet. Since you are doing a new number, you may have to wait longer. And there is no guarantee that new numbers will be processed in that same 24-48 hour timeframe. And there is no guarantee about when Apple will recognize the number. I think the rumours ten year ago were two weeks. I suggest waiting a month after confirmation from Dun & Bradstreet.

But when I use the newer API (that you say is identical to the old, or rather that the 'old' API translates to the newer) This caught my eye so I went back over your code and the problem is that you're NOT making the same API call. Here is the code from your original post: res = es_mute_path(self.esClient, [mutePath UTF8String], ES_MUTE_PATH_TYPE_TARGET_LITERAL); You passed ES_MUTE_PATH_TYPE_TARGET_LITERAL, which means: ES_MUTE_PATH_TYPE_TARGET_LITERAL-> The command targets this specific You should have passed ES_MUTE_PATH_TYPE_LITERAL, which means: ES_MUTE_PATH_TYPE_LITERAL-> The executable path is I actually copied that mistake in my previous reply so, correcting my mistake, these calls are direct equivalents. res = es_mute_path_literal(...); and res = es_mute_path(..., ES_MUTE_PATH_TYPE_LITERAL); Finally, on this point: I don't know how to extract a simple C project to demonstrate the issue, because my code is big and quite complicated, but I will make an attempt to provide such a sample. Th

The edge cases and qualifiers you provide here are very far from my needs. Most executables I want to mute are well protected by SIP, and will never move (MacOS private frameworks, daemons etc. plus few third-party that are also very well defined). My issue is very blunt. I mute a simple and perfect executable path. Here are some - my list is much longer, but you'll get the idea: +(NSSet *) baseBinaryPathWhitelist { static NSSet *_baseBinaryPath = nil; // any executable in these specific paths will be ignored static dispatch_once_t onceToken; dispatch_once(&onceToken, ^{ _baseBinaryPath = [NSSet setWithArray: @[ NSProcessInfo.processInfo.arguments[0], // don't inspect our own ITProtector process. @/sbin/launchd, @/bin/launchctl, @/bin/ps, @/bin/sleep, @/usr/bin/dscl, @/usr/bin/log, @/usr/bin/vmmap, @/usr/sbin/syslogd, @/usr/sbin/spindump, @/usr/sbin/usernoted, @/usr/sbin/securityd, @/usr/sbin/ipconfig, @/usr/libexec/biomesyncd, @/usr/libexec/logd]; But when I use the newer API (that you say is identical t