Hi, I try to to read a file from Swift using class FileHandle and function Swift @available(macOS 10.15.4, iOS 13.4, watchOS 6.2, tvOS 13.4, *) public func read(upToCount count: Int) throws - Data? This works fine in principle. However, I'm faced with a memory leak. The data allocated in the returned Data buffer is not freed. Is this possibly a bug in the underlying Swift wrapper? Here is my test function, which reads a file block by block (and otherwise does nothing with the data). Swift func readFullFile(filePath: String) throws { let blockSize = 32 * 1024 guard let file = FileHandle(forReadingAtPath: filePath) else { fatalError("Failed to open file") } while (true) { guard let data = try file.read(upToCount: blockSize) else { break } } } If I call the function in a loop, and watch the program's memory consumption, it's obvious that the memory goes up in each loop by the size of the read file. Can anybody confirm this behavior or knows how to fix it or if there's possibly already a bug issue opened at Apple? My environment: macOS 11.3.1 Big Sur XCode 12.5 Best, Michael

Hello, we have developed a kernel extension (KEXT) for a virtual file system (VFS) to integrate our software with external programs like Adobe InDesign or Microsoft Word. Our software and the KEXT are used by many of our customers. As it looks like KEXTs are deprecated and may be removed completely in future versions of macOS, particularly on Apple Silicon based computers. See e.g. Apple's announcement in its security guide: "This is why developers are being strongly encouraged to adopt system extensions before kext support is removed from macOS for future Mac computers with Apple silicon" Therefore we are currently investigating in possible alternatives. Apple suggests to migrate to System Extensions instead of KEXTs. However, the only VFS related API we found is to implement a File Provider that is based on an NSFileProviderReplicatedExtension. Unfortunately that NSFileProviderReplicatedExtension has several flaws: Files can either be in the cloud or downloaded. It is not possible to download/read only a portion of a file. This is a big performance problem for us, since we work with large images (> 1GB). The programs we integrate with typically only read a part of the image, e.g. the embedded preview. The API does not offer a way to access selected blocks of a file (random access file). The File Provider learns about the file system content via enumerators. So everything that is inside a folder must be enumerated (listed) first. Otherwise it cannot be accessed. However, we cannot enumerate our VFS. Most of the content of our VFS is fully dynamic. It only exists when it is accessed by a client the first time. Such dynamic content also includes dynamic parameters like the client's locale or the size of a box where the image will be placed. Since we do not know those parameters in advance, we cannot enumerate the VFS's content in advance. This means, an NSFileProviderReplicatedExtension in its current state isn't a replacement for a "real" VFS and therefore cannot be used by us as a replacement for our current VFS KEXT. My questions: Will Apple allow kernel extensions also in future versions of (Apple Silicon/M1 based) operating systems? Or is there at least a clear deadline? If not, what is Apple's officially suggested replacement for KEXT based VFS solutions? Will the API of an NSFileProviderReplicatedExtension be improved to behave like a "real" file system so that above mentioned flaws will no longer be an issue? Many thanks for any answers or comments! Best regards, Michael

Hello, I installed macOS 11.0.1 (Big Sur) in VMware Fusion 11. Unfortunately I'm no longer able to boot the OS into recovery mode (CMD+R). The VM seems to make an endless restart in this case until I release the keys. Then it boots into normal mode. For my VM with macOS Catalina with exact same settings this works just fine. Has anybody experienced similar behavior and/or knows how to fix this problem? My host environment: macOS Catalina 10.15.7, MacBook Pro (15-inch, 2018), 2,9 GHz 6-Core Intel Core i9, 32 GB 2400 MHz DDR4 Best Michael

Hi community, we have a kernel extension (kext) that is serving as a virtual filesystem (VFS). Until now we've used a local socket for the communication between kernel-space and user-space. Unfortunately sockets are provided by sys/kpi_socket in the kernel which is deprecated from macOS 10.15 on and - according to Apple's announcement and release notes - unsupported from Big Sur (macOS 11) on. However: We now made tests on the latest macOS Big Sur 11.0.1. And apparently the deprecated KEXT can still be loaded and it is working as expected. Does anybody know why? Has Apple changed its mind in the very last minute? Thanks and best Michael See also: related question - https://developer.apple.com/forums/thread/659502

Hello, I installed macOS 11.0.1 (Big Sur) in VMware Fusion 11. When opening a JPEG (or PNG) image from the desktop via quick view (SPACE) or in Preview app via double click it takes several seconds until the image becomes visible. During that time the computer seems to be completely blocked. An open system information window is also not getting updates. It becomes even worse when the eventually appearing quick view window is closed again. Then the computer hangs for up to one minute. A colleague was able to reproduce the exact same behavior, but using a different hypervisor: Parallels. For me it does not look like a bug in VMware, but a bug in Big Sur itself when running on a hypervisor. Has anybody experienced similar behavior? I would also be thankful for any hints where to report this issue officially. Thanks! My host environment: macOS Catalina 10.15.7, MacBook Pro (15-inch, 2018), 2,9 GHz 6-Core Intel Core i9, 32 GB 2400 MHz DDR4 Best Michael PS: Just for completeness: macOS Catalina is running smoothly in VMware on my machine with exact same VM settings.

Hello, we are currently investigating how to migrate our VFS kext (Kernel extension for a virtual file system) to macOS Big Sur. See related question - https://developer.apple.com/forums/thread/659502 As suggested, we plan to replace the deprecated kernel socket API with KEXT Controls. Now we noticed that the callback function (configured in ctl_register) to receive the data sent by the client (from user space) uses a memory buffer (mbuf): typedef errno_t (*ctl_send_func)(kern_ctl_ref kctlref, u_int32_t unit, void *unitinfo, mbuf_t m, int flags); However, according to the source code documentation, memory buffers are deprecated as well. Does this mean: Memory buffers won't work on Big Sur as well? Is there a way to avoid using memory buffers when using KEXT Controls? Thanks and regards Michael