“smb big sur”

So there are actually two different issues at play here. The broad issue here: Hi, am facing an issue related to voip push notifications getting delivered 1-2 hours after apns-expiration to 0 and apns-priority to 10. ...is a long standing issue with APNS. Basically, if a push is prepped for delivery (because the server believes delivery is possible) but delivery fails, that push can end up being left in the queue and then delivered much later if/when the client device is again able to reconnect. I'd appreciate you taking the time to file a bug on this and then posting the bug number back here. I'd like to see us address this but, unfortunately, there have been a lot fewer bugs filed about it than you'd expect. The second issue is here: Now if a caller makes call to this app, the call should be delivered through voip push. 2) Voip push should ideally be received even if app is in background and iPhone is locked. It is connected to a good wifi network. But it does not receive the voip push. The exact details va

[quote='778201021, lev-ftnt, /thread/778201, /profile/lev-ftnt'] Or are there limitations that would prevent implementing a full IKEv2 stack this way? [/quote] I don’t have a good enough on IKEv2 to give you a definitive answer to this. I suspect that you’ll be generally OK, but I wouldn’t be surprised if you run into the odd speedbump. I am aware of one thing that the built-in IKEv2 can do that an NE packet tunnel provider can’t do, namely support Always-on VPN. I’m presuming that’s not a big deal for you. [quote='778201021, lev-ftnt, /thread/778201, /profile/lev-ftnt'] because we need to add extra information to EAP [/quote] Is this something generally useful? Or extremely specific to your environment? If it’s the former, I encourage you to file an enhancement request for that feature, regardless of what else you do. And in this case, please post your bug number, just for the record. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

I don't see issues in your code with a quick glance but it is quite a big code base. My recommendation would be to make a small test project that just loads the model and makes a prediction. We can then tell whether the issue is in the model or in the usage of CoreML API (or somewhere else.)

Specifically comparing searchfs vs getatrrlistbulk, if you end up having read the entire catalog structure off disk, then that cost can mask any performance difference. I just did a new comparison: I compared how searchfs compares vs. recursive dir scan on HFS+ vs. APFS. On SSDs, of course. Always searching for a non-existing file name (so that no extra attributes need to be collected). A search on a HFS+ vol with 8.8M items (6.6M files, 2.2M dirs) on a fast Intel system: searchfs: 40s find: 270s And on a HFS+ vol with 2.6M items (2M files, 600k dirs), Mac Mini 2018: searchfs: 11s find: 70s We can see that the search locally in the FS makes a huge different here. About factor 6 each time. Probably due to the many kernel-user space transitions. Now a search on APFS, with 1.75M items (1.5M files and 250k dirs), on an M4 Mini: searchfs: 13s find: 35s And APFS with 490k items (360k files, 130k dirs), on an Intel Mini 2018: searchfs: 9s find: 40s So, there's still a difference, but smaller. Which may suggest that

[quote='830819022, DTS Engineer, /thread/776198?answerId=830819022#830819022'] However, the real benefit here isn't local filesystem, it's remote file system case where the core cost isn't the direct syscall cost, but the cost of transferring all of those individual file records.[/quote] Right - but that huge advantage was lost when Apple decided to drop AFP support and didn't add such a feature to SMB. (And this is part of my current pain having to find alternative search methods (https://findanyfile.app/fs/) for various servers, such as Spotlight, SSH login with find execution on the server, using Everything's http server on Windows, and so on. It was all so easy when we had AFP). Is there even any supported network file system left that supports searchfs? Does NFS (I believe I never checked because it's so diffucult to use)?

The answer to your exact question is “No.” The iOS SDK is embedded within Xcode. Xcode is signed, and removing anything from the SDK would break the seal on its code signature. Can you take a step back and explain more about the big picture goal here? The iOS SDK is not exactly huge — currently about 81 MB on disk — so it’s not clear why you think that removing stuff is important. Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com

This company does not act impartially. It closes accounts for no reason to pave the way for big companies. It does not even respond.

Hi and thanks for your response. I am just a hobbyist developer who writes MacOS apps for personal use on my machines at home; as such I just sign them to run locally and do not really have a need to be involved in archiving and distribution build processes. Currently I will make changes, etc, create a debug build for testing; afterwards will create a release build that will be used for execution; after creating this release build I open the build folder while still in Xcode and manually copy the app to my application directory. My goal (as stated in the question I raised) is to somehow have that copying incorporated into the build process for the release build. It is not a big deal, just seemed like there should be a way to do it.

Wow, Kevin. That's excellent support, thank you so much for making the effort! I had no idea that using concurrency in file system calls would have any such effect. You proved me wrong. In a real implementation, I think you'd probably want a fixed set of threads calling getattrlistbulk, another set of threads processing the data each call produced, and then system the pushed directory back to the syscall thread. Already doing all the processing past the initial gathering of the directory contents in a separate thread, but that's clearly far from what's possible. I actually tracked this bug down and I have a question about your testing. Were you always testing on freshly mounted volumes (meaning, umount volume-> mount volume-> searchfs)? Or did you also test on volumes under normal use and repeatedly running searchfs? The use case of my app is to mainly run searches on the entire startup volume. So that's what I focused on with my tests. I try to be aware of caching effects (I believe some OS versions ca

I also agree that some of the properties, such as NSURLIsVolumeKey shouldn't be costly because they should not require another call into the BSD/POSIX APIs as I'd have thought that the information is already present at the level above the VFS. And that's especially true for the NSURLIsDirectoryKey. No, it doesn't work that way. More specifically, there are basically two levels where caching can occur: At the system level, where all processes have a coherent view of what they believe the file systems current state is. At the process level, where processes have whatever data they last received from #1. The key issue here is that the system level cache IS the VFS layer. The POSIX APIs operate as the bridge between those two layers and that means they minimize any kind of caching (since that would only complicate the bridge). That is, the ony level above the VFS layer IS NSURL. It should be caching the data it's getting from getattrlistbulk (that's one of it's jobs) and it shouldn't be seeing the large performanc

I've noted down your comments, though, in case I have to work on this again. I have a concern about performance, though: I like to be as fast as possible with the iteration, especially if I only need to look at file names. So, my first and biggest warning here is that this kind of performance testing is excruciatingly tricky and error prone. There are so many details and edge cases that distort the results, all of which make it very hard to be entirely confident in any conclusion. The next thing to understand here is that the fundamental performance issues and the corresponding solutions are EXACTLY the same across basically all of the APIs your looking at. More specifically, going back to your article here: https://blog.tempel.org/2019/04/dir-read-performance.html ...you reference basically 3 APIs. Here are the APIs and their underlying implementation: contentsOfDirectoryAtURL-> Implemented as a wrapper around enumeratorAtURL, which is wrapper around getattrlistbulk. opendir()/readdir_r()-> Wrapper aro