smb big sur

I have built over hundreds of websites using Flutter Web in the last 4 years. Now, I am in big trouble.

Hi @DTS Engineer, Thank you for your assistance and support. Regarding the issue of a file being exclusively locked by Quick Look Extension Preview, I believe this might be an oversight. Here are some points to consider: Prior to macOS 15, the Quick Look Generator Preview functioned without this issue. However, the Quick Look Extension Preview exhibits this problem. In the Quick Look Extension system, thumbnail generation works without issue, but preview generation does not. As Alberto pointed out, text previews are unaffected, whereas image previews are impacted. Quick Look does not seem to require an exclusive lock on a file for reading purposes. Given these observations, it seems likely that the exclusive lock behavior in the Quick Look Extension Preview, when accessing files over SMB, in unintentional. If this is not an oversight, could you kindly explain why an exclusive lock is necessary in the Quick Look Extension Preview? This insight would help us better understand the situation and explore

its hard to find the emoji I need because they’re too big, and it’s making my texting language weird now because I can’t find the one I need. It’s too many pages to scroll through. My eye sight is medically normal. 20/20. can we please go back to normal size? 🙏

Sorry about the delay responding; I’m juggling too many cases right now. I’m going to start with the big picture: [quote='813576022, harshal_goyal, /thread/766557?answerId=813576022#813576022, /profile/harshal_goyal'] While we are exploring mDNS-based discovery using Bonjour, our primary goal is to create cross-platform applications … [/quote] Support for the Bonjour protocols [1] are either built-in or readily installable on all major platforms. [quote='813576022, harshal_goyal, /thread/766557?answerId=813576022#813576022, /profile/harshal_goyal'] we are focused on process discovery—identifying processes running on the same network, regardless of whether they expose a service. [/quote] OK. But that doesn’t preclude the use of Bonjour, you just need to think of each process as a service. [quote='813576022, harshal_goyal, /thread/766557?answerId=813576022#813576022, /profile/harshal_goyal'] We are avoiding the use of multicast DNS (mDNS) because it adds overhead and costs. [/quote] What sort of overhe

The most disturbing emoji new look! U can not choose from the small banner down specially the recent, then emojis are too big so it takes ages to scroll between pages to find the right emoji… please need a solution to this asap 😭😭😭😭 just bring the emoji display as it was

It’s hard to answer this without a lot more details. In general, macOS and the notary service continue to tighten up their checking of code in order to close security holes. Some of those are big changes, when we tend to announce widely. I have a bunch of links to such things in Trusted Execution Resources and the other Resources posts that it links to. But some of them are relatively minor changes that don’t get widely advertised. And some changes are just implementation changes that happen to cause problems for code that’s not following the rules [1]. [quote='770552021, hamish258, /thread/770552, /profile/hamish258'] DMGs built, signed and notarised successfully are now failing codesign verification. [/quote] If you run syspolicy_check against such an app, what does it report? Share and Enjoy — Quinn “The Eskimo!” @ Developer Technical Support @ Apple let myEmail = eskimo + 1 + @ + apple.com [1] Historically those rules were very poorly documented. That’s much better these days, but lots of code, a

I agree with Ed, that the “Leaks” instrument is not as illuminating as the “Allocation” instrument. The “Leaks” instrument is most useful (in those edge-cases) where you are writing code that does manual alloc/free or retain/release. If not, it is generally identifying (usually very small) issues largely outside of your control. But if you don’t have your own code that is doing alloc/free or retain/release, the “Leaks” instrument is not terribly illuminating. Your “Debug Memory Graph” diagnostics, though, are very effective in identifying strong reference cycles. But rather than focusing on the bottom of the tree (the fact that the NSSet was used deeply within Foundation types), I would focus on the top of that tree. E.g., it looks like the NSSet was created by some AVFoundation layer view. So, I would focus on the AVFoundation usage within the app. Even better, in the left panel of the “Debug Memory Graph”, I would advise that we focus on our own objects, i.e., those objects over which we have control. To th

I am also facing same issue rejection of my app reason provided by apple that HealthKit is being referred in the code But I have checked all the libraries with otool and then info plist , all the capabilities .. No reference to HealthKit in my app. Only think My code has some methods names which contain HealthKit inside their big names... Can Apple reject my app coz of it ?

Of course, but that is not what is happening here. At most one file is being created, a .DS_Store file. Having encountered this problem before in a strictly local context, I changed my program to retry and that has worked (with local files). If the problem is APFS delaying the deletion of the directory, then perhaps I need a longer timeout on my retry loop? To clarify, I don't think APFS itself is a key factor. How long is your current retry timing? Certainly comparing local and network volumes, much longer timeouts are often required for a network file system. The real problem is not the failure to delete the directory, it is inconsistent state that is created (as viewed by a network client). What does viewed here actually mean? How the user actually looking at the file/directory? The complication here is around exactly happened here: Apparently, the file server believes the directory exists (it shows up when remotely listing the parent) even after the directory ceases to exist (as viewed on the server file

First off, jumping back to here: Using the lsof command, it seems like the Quicklook process has some kind of lock on the file. This is the output of the lsof command: Have you tried sampling (with Activity Monitor) the Quicklook process when it's in this state? I'd like to see if it's idled again or if it thinks it's doing something useful. We do need to support Windows clients connected to networks shares since our app is cross-platform. Our team has in fact proved in the past that open(url.path, O_RDWR | O_NONBLOCK | O_EXLOCK) does work over SMB shares and we're reluctant to switch to a totally different locking system. OK. My main warning here is that, in my experience, belief in how well this work is directly proportional to how broad the testing process has been. Given this additional information, do you think there's anything we can do to address the issue? I don't know. The immediate thing I would try here is changing what's your actually doing/returning, both by either using the draw reply o