I know you guys probably dont care or what to help with this but I got taken down in the support communities because I simply run a beta version (didn’t even discuss it) but here we go **My MacBook Air has multiple accounts and the other users & shared category takes up 100+ gb. When I sign into one of the accounts, that 100+ gb gets moved to System Data. When I look in finder, the user only seems to take up 12 gb, though. I’ve shown hidden items and looked through the library, but it’s not showing anything that’s taking up that much space! **

Hi Apple team, I'm experiencing a persistent issue with writing to UserDefaults from a widget extension on iOS. Here's the situation: I've set up an App Group: group.test.blah The main app has the correct entitlement and can read/write from UserDefaults(suiteName:) using this group successfully. I can read the value written by the app from the widget (e.g., "testFromApp": "hiFromApp"). The widget extension has the same App Group enabled under Signing & Capabilities. The provisioning profile reflects the App Group and the build installs successfully on a real device. The suite name is correct and matches across both targets. I’ve confirmed via FileManager.default.containerURL(...) that the app group container resolves properly. When I try to write from the widget extension like this let sharedDefaults = UserDefaults(suiteName: "group.test.blah") sharedDefaults?.set("hiFromWidget", forKey: "testFromWidget") ...I get this error in the console: Couldn't write values for keys ( testFromWidget ) in CFPrefsPlistSource<0x1140d2880> (Domain: group.test.blah, User: kCFPreferencesCurrentUser, ByHost: No, Container: (null), Contents Need Refresh: No): setting preferences outside an application's container requires user-preference-write or file-write-data sandbox access Questions: What could still cause the widget extension to lack write access to the app group container, even though it reads just fine? Are there any internal sandboxing nuances or timing-related issues specific to Live Activity widgets that could explain this? Is this a known limitation or platform issue?

working on app like dropbox and making a feature like dropbox offline download, so when a file is added from a system it will download in other system but as a placeholder file once user double click or open that file or after copy pasting to another location on demand need to download the file and after that do the action open or paste so here I need file open event and paste event to be block untill it downloads. how to achieve this uing obj c, c , c++ or swift

I have an app which uses ubiquitous containers and files in them to share data between devices. It's a bit unusual in that it indexes files in directories the user grants access to, which may or may not exist on a second device - those files are identified by SHA-1 hash. So a second device scanning before iCloud data has fully sync'd can create duplicate references which lead to an unpleasant user experience. To solve this, I store a small binary index in the root of the ubiquitous file container of the shared data, containing all of the known hashes, and as the user proceeds through the onboarding process, a background thread is attempting to "prime" the ubiquitous container by calling FileManager.default.startDownloadingUbiquitousItemAt() for each expected folder and file in a sane order. This likely creates a situation not anticipated by the iOS/iCloud integration's design, as it means my app has a sort of precognition of files it should not yet know about. In the common case, it works, but there is a corner case where iCloud sync has just begun, and very, very little metadata is available (the common case, however, in an emulator), in which two issues come up: I/O may hang indefinitely, trying to read a file as it is arriving. This one I can work around by running the I/O in a thread created with the POSIX pthread_create and using pthread_cancel to kill it after a timeout. Attempts to call FileManager.default.startDownloadingUbiquitousItemAt() fails with an error Error Domain=NSCocoaErrorDomain Code=257 "The file couldn’t be opened because you don’t have permission to view it.". The permissions aspect of it is nonsense, but I can believe there's no applicable "sort of exists, sort of doesn't" error code to use and someone punted. The problem is that this same error will be thrown on any attempt to access that file for the life of the application - a restart is required to make it usable. Clearly, the error or the hallucinated permission failure is cached somewhere in the bowels of iOS's FileManager. I was hoping startAccessingSecurityScopedResource() would allow me to bypass such a cache, as it does with URL.resourceValues() returning stale file sizes and last modified times. But it does not. Is there some way to clear this state without popping up a UI with an Exit button (not exactly the desired iOS user experience)?

Here's the problem I'm trying to solve: Create an iOS app which can scan the Downloads folder (where airdropped audio files arrive), identify audio media files, and play them, retaining some of its own metadata about them (basically, create textual notes mapped to timestamps and store that information in the apps own storage). I am not able to access that folder. I am able to get a path from NSSearchPathForDirectoriesInDomains(FileManager.SearchPathDirectory.downloadsDirectory, FileManager.SearchPathDomainMask(arrayLiteral: FileManager.SearchPathDomainMask.userDomainMask), true) or a URL from NSSearchPathForDirectoriesInDomains(FileManager.SearchPathDirectory.downloadsDirectory, FileManager.SearchPathDomainMask(arrayLiteral: FileManager.SearchPathDomainMask.userDomainMask), true) but let fileUrls = try fileManager.contentsOfDirectory(at:downloads, includingPropertiesForKeys: []) fails with an error that the folder does not actually exist, with or without a call to downloadsUrl.startAccessingSecurityScopedResource(). Determining whether this is a permissions issue, or if I'm getting a URL to an application-container local folder that has nothing to do with the one I am looking for is compounded by the fact that if I set the build setting Enable App Sandbox, then deployment to my phone fails with Failed to verify code signature. I have spent hours trying every possible combination of certificates and deployment profiles, and ensured that every possibly relevant certificate is trusted on my phone. Disable app-sandbox and it deploys fine, either with automatic signing or an explicit cert and profile. I have an entitlements file with the following - though, without the ability to enable app sandbox and run it on a phone with actual contents in the downloads folder, it is probably not affecting anything: <key>com.apple.security.files.downloads.read-only</key> <true/> <key>com.apple.security.files.user-selected.read-only</key> <true/> <key>com.apple.security.app-sandbox</key> <true/> So, questions: Should the URL returned by the above call be the Downloads/ folder airdropped to in the first place? Or is it a URL to some app-local folder that does not exist? Does the entitlement com.apple.security.files.downloads.read-only even allow an app to list all files in the downloads directory (presumably asking the user's permission the first time), or does the permission only get requested when using a picker dialog? (the point here is to find any new audio files without making the user jump through hoops) If I could get it deployed with app-sandbox enabled, would the above code work? Backstory: I'm a software engineer, audio plugin author, Logic Pro user and musician. My workflow (and probably many other Logic user's) for work-in-progress music is to airdrop a mix to my phone, listen to it in a variety of places, make notes about what to change, edit - rinse and repeat. For years I used VLC for iOS to keep and play these in-progress mixes - you could airdrop and select VLC as the destination (yes, Logic can add to your Apple Music library, but trust me, you do not want 20 revisions of the same song cluttering your music library and sync'd to all your devices). Last year, the behavior of Airdrop changed so that the target app for audio is always Files, period, wrecking that workflow. While I eventually discovered that, with an elaborate and non-obvious dance of steps, it is possible to copy files into VLC's folders, and make them available that way, it is inconvenient, to say the least - and VLC is less than fabulous anyway - it would be nice to have an app that could associate to-do notes with specific timestamps in a tune, A/B compare sections between old and new versions and things like that. So, figuring sooner or later I was going to get into a car accident futzing with the Files app to listen to mixes while driving, perhaps I should write that app. But the ability to do that at all relies on the ability of an app to list and access the Downloads folder airdropped audio files land in (assuming the user has given permission to access it, but that should be needed once).

Hi, I'm having trouble implementing iCloud Drive in my app. I've already taken the obvious steps, including enabling iCloud Documents in Xcode and selecting a container. This container is correctly specified in my code, and in theory, everything should work. The data generated by my app should be saved to iCloud Drive in addition to local storage. The data does get stored in the Files app, but the automatic syncing to iCloud Drive doesn’t work as expected. I’ve also considered updating my .entitlements file. Since I’m at a loss, I’m reaching out for help maybe I’ve overlooked something important that's causing it not to work. If anyone has an idea, please let me know. Thanks in advance!

Hello everyone, I am new to swift development and I am currently facing a "bug". I am building, an app on my Mac mini. It's working fine on my machine but when exporting the executable on a MacBook Air, one of my feature does not work anymore. I should be able to drag and drop a PDF which should be copy to my App document folder. But for some reason it won't work. I should add that : The app is sandboxed I tried to build the app on the MacBook Air and it does not work either. I gave all the permission to the app in the MacBook Air parameter menu. I have another drag and drop functionality with read a csv file, and it works. With Xcode, the error message was about : file not found (after being read and recognized on my log) I hope someone would have some ideas Thank you in advance PS: I'm French, sorry for my English

Hello everyone, I'm developing a macOS application that programmatically sets custom icons for folders, and I've hit a wall trying to get Finder to display the icon changes consistently. The Goal: To change a folder's icon using NSWorkspace.shared.setIcon and have Finder immediately show the new icon. What I've Tried (The Refresh Mechanism): After setting the icon, I attempt to force a Finder refresh using several sandbox-friendly techniques: Updating the Modification Date (the "touch" method): try FileManager.default.setAttributes([.modificationDate: Date()], ofItemAtPath: pathToUse) Notifying NSWorkspace: NSWorkspace.shared.noteFileSystemChanged(pathToUse) Posting Distributed Notifications: DistributedNotificationCenter.default().post(name: Notification.Name("com.apple.Finder.FolderChanged"), object: pathToUse) The Problem: This combination of methods works perfectly, but only under specific conditions: When setting a custom icon on a folder for the first time. When changing the icon of an alias. For any subsequent icon change on a regular folder, Finder stubbornly displays the old, cached icon. I've confirmed that the user can see the new icon by manually closing and reopening the folder window, but this is obviously not a user-friendly solution. Investigating a Reset with AppleScript: I've noticed that the AppleScript update command seems to force the kind of complete refresh I need: tell application "Finder" update POSIX file "/path/to/your/folder" end tell Running this seems to reset the folder's state in Finder, effectively recreating the "first-time set" scenario where my other methods work. However, the major roadblock is that I can't figure out how to reliably execute this from a sandboxed environment. I understand it likely requires specific scripting entitlements, but it's unclear which ones would be needed for this update command on a user-chosen folder, or if it's even permissible for the App Store. My Questions: Is there a reliable, sandbox-safe way to make the standard Cocoa methods (noteFileSystemChanged, updating the modification date, etc.) work for subsequent icon updates on regular folders? Am I missing a step? If not, what is the correct way to configure a sandboxed app's entitlements to safely run the tell application "Finder" to update command for a folder the user has granted access to? Any insight or alternative approaches would be greatly appreciated. Thank you

content = try String(contentsOfFile: filepath) is the following warning. 'init(contentsOfFile:)' was deprecated in iOS 18: Use init(contentsOfFile:encoding:) instead After internet searching I could find an answer. I would appreciate a rewrite of my code line to get rid of 31 warnings. Thanks a LOT Charlie

After creating a hardlink on a distributed filesystem of my own via: % ln f.txt hlf.txt Neither the original file, f.txt, nor the hardlink, hlf.txt, are immediately accessible, e.g. via cat(1) with ENOENT returned. A short time later though, both the original file and the hardlink are accessible. Both files can be stat(1)ed though, which confirms that vnop_getattr returns success for both files. Dtruss(1) indicates it's the open(2) syscall that fails: % sudo dtruss -f cat hlf.txt 2038/0x4f68: open("hlf.txt\0", 0x0, 0x0) = -1 Err#2 ;ENOENT 2038/0x4f68: write_nocancel(0x2, "cat: \0", 0x5) = 5 0 2038/0x4f68: write_nocancel(0x2, "hlf.txt\0", 0x7) = 7 0 2038/0x4f68: write_nocancel(0x2, ": \0", 0x2) = 2 0 2038/0x4f68: write_nocancel(0x2, "No such file or directory\n\0", 0x1A) = 26 0 Dtrace(1)ing my KEXT no longer works on macOS Sequoia, so based on the diagnostics print statements I inserted into my KEXT, the following sequence of calls is observed: vnop_lookup(hlf.txt) -> EJUSTRETURN ;ln(1) vnop_link(hlf.txt) -> KERN_SUCCESS ;ln(1) vnop_lookup(hlf.txt) -> KERN_SUCCESS ;cat(1) vnop_open(/) ; I expected to see vnop_open(hlf.txt) here instead of the parent directory. Internally, hardlinks are created in vnop_link via a call to vnode_setmultipath with cache_purge_negatives called on the destination directory. On macOS Monterey for example, where the same code does result in hardlinks being accessible, the following calls are made: vnop_lookup(hlf.txt) -> EJUSTRETURN ;ln(1) vnop_link(hlf.txt) -> KERN_SUCCESS ;ln(1) vnop_lookup(hlf.txt) -> KERN_SUCCESS ;cat(1) vnop_open(hlf.txt) -> KERN_SUCCESS ;cat(1) Not sure how else to debug this. Perusing the kernel sources for uses of VISHARDLINK, VNOP_LINK and vnode_setmultipath call sites did not clear things up for me. Any pointers would be greatly appreciated.

Currently, I use NSFileProviderItemCapabilitiesAllowsAddingSubitems on a folder to control the creation of sub-items (either folders or files) within a parent folder. However, this capability doesn't allow me to meet a requirement where I need to permit file creation but restrict folder creation. I am seeking input on different options to achieve this requirement. Note: One reactive approach would be to intercept folder creation within the createItem() event handler and reject it with an ExcludedFromSync error (without uploading to cloud). This would prevent createItem() from being reattempted on that folder, but the folder would still remain on the mount. Is there any way to delete it?

Dear Apple: We are developing a file management-related app, I want to configure com.apple.security.temporary-exception.files.absolute-path.read-write to /Users/*** in the entitlements. Will this affect the approval process of our app on the App Store?

Dear Apple: We are developing a file management-related app, and I would like to retrieve the list of files from the "Recents" section under "Favorites" in the Mac sidebar, then display this information in the app's interface for users. Is there an API available to obtain this information?

I reported this as a bug (FB18614667), but also wanted to ask here in case this is actually just me doing something wrong, or maybe I'm misunderstanding the entire use case of metadataRead. (My understanding is that metadataRead is basically read but it checks a cache that the kernel manages before trying to read the physical resource, and in the case of a cache miss it would just go to the physical resource and then add the bytes to the cache. Is that right?) I’m encountering an issue in an FSKit file system extension where (for example) read(into: buf, startingAt: 0, length: Int(physicalBlockSize)) works, but metadataRead(into: buf, startingAt: 0, length: Int(physicalBlockSize)) throws an EIO error (Input/output error) no matter what I do. (Note: physicalBlockSize is 512 in this example.) The documentation (https://developer.apple.com/documentation/fskit/fsblockdeviceresource/metadataread(into:startingat:length:)) indicates that the restrictions on metadataRead are that the operations must be sector-addressed (which is the case here, especially as regular read has the same restriction and succeeds) and that partial reading of metadata is not supported. (I don’t think that applies here?) In a sample project I was able to replicate this behavior where the module only ever reads the block device in its enumerateDirectory implementation, and so trying to list the contents of a directory leads to an "Input/output error" when e.g. running ls on the volume. The enumerateDirectory sample implementation is like so: func enumerateDirectory(_ directory: FSItem, startingAt cookie: FSDirectoryCookie, verifier: FSDirectoryVerifier, attributes: FSItem.GetAttributesRequest?, packer: FSDirectoryEntryPacker) async throws -> FSDirectoryVerifier { let buf = UnsafeMutableRawBufferPointer.allocate(byteCount: Int(blockDevice.physicalBlockSize), alignment: 1) defer { buf.deallocate() } // metadataRead will throw... try blockDevice.metadataRead(into: buf, startingAt: 0, length: Int(blockDevice.physicalBlockSize)) // but read will work. // try await blockDevice.read(into: buf, startingAt: 0, length: Int(blockDevice.physicalBlockSize)) // ... return dummy file here (won't reach this point because metadataRead throws) } I'm observing this behavior on both macOS 15.5 (24F74) and macOS 15.6 beta 3 (24G5074c). Has anyone been able to get metadataRead to work? I see it used in Apple's msdos FSKit implementation so it seems like it has to work at some level.

We create plug-ins for Adobe Creative Cloud and have run into an issue with respect to file/folder permissions. First, all of our libraries, code is code-signed and notarized as per Apple requirements but distribute outside of the Mac App store. We install a Photoshop plug-in and its mainly a UI which then executes a background app containing the business logic to read/write files. The background app runs as a separate process and is not in the Photoshop sandbox space so it doesn't inherit Photoshop permissions/scoping rules. Our plug-in communicates with the background process via ports etc. When a user chooses a file to process from lets say the Desktop, generally macOS first pops up a message that says ABCD background app is trying to access files from the Desktop do you grant it permission etc...This is also true for network mounted volumes or downloads folder. This message generally appears properly when everything is under an account with admin rights. However, when our tool is installed from a Standard Account, the macOS messages asking for confirmation to access the Desktop or Documents or Downloads folder doesn't appear and access to the file/folders is denied. Thus our background only process errors out. Looking at the Security and Privacy->Files and Folders the button to enable access is in the Off position. If we turn these on Manually, everything works. But this is a really poor user experience and sometimes our users think our software is not working. Does anybody have any idea how to allow for the file/folder permissions to be registered/granted in such a case? Should we try to register these as Full Disk Access? Any ideas and/or solutions are welcome.

Getting "Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file" unexpectedly while attempting to create a small log file. Here's some background. This is a Swift app I wrote for my own use six years ago. A week ago, I made a small update to the app, which has not been changed in over two years. First time using Xcode 16.4 on this app, which required some code updates of course. The code creating this file has not been changed. Now for the first time, I'm getting this permissions error on a folder with wide-open permissions. This is the code. Worked for years under previous versions of Xcode. * if let outputURL = URL(string: "file://" + logPath + "/output_" + outputFormatter.string(from:Date()) + ".txt"){ do{ try outputString.write(to: outputURL, atomically:false, encoding: .utf8) }catch let error as NSError{ print ("log write error (error) (nl) (outputString)") } }

I have discovered a gap in my understanding of user selected URLs in iOS, and I would be grateful if someone can put me right please. My understanding is that a URL selected by a user can be accessed by calling url.startAccessingSecurityScopedResource() call. Subsequently a call to stopAccessingSecurityScopedResource() is made to avoid sandbox memory leaks. Furthermore, the URL can be saved as a bookmark and reconstituted when the app is run again to avoid re-asking permission from the user. So far so good. However, I have discovered that a URL retrieved from a bookmark can be accessed without the call to url.startAccessingSecurityScopedResource(). This seems contrary to what the documentation says here So my question is (assuming this is not a bug) why not save and retrieve the URL immediately in order to avoid having to make any additional calls to url.startAccessingSecurityScopedResource? Bill Aylward You can copy and paste the code below into a new iOS project to illustrate this. Having chosen a folder, the 'Summarise folder without permission' button fails as expected, but once the 'Retrieve URL from bookmark' has been pressed, it works fine. import SwiftUI import UniformTypeIdentifiers struct ContentView: View { @AppStorage("bookmarkData") private var bookmarkData: Data? @State private var showFolderPicker = false @State private var folderUrl: URL? @State private var folderReport: String? var body: some View { VStack(spacing: 20) { Text("Selected folder: \(folderUrl?.lastPathComponent ?? "None")") Text("Contents: \(folderReport ?? "Unknown")") Button("Select folder") { showFolderPicker.toggle() } Button("Deselect folder") { folderUrl = nil folderReport = nil bookmarkData = nil } .disabled(folderUrl == nil) Button("Retrieve URL from bookmark") { retrieveFolderURL() } .disabled(bookmarkData == nil) Button("Summarise folder with permission") { summariseFolderWithPermission(true) } .disabled(folderUrl == nil) Button("Summarise folder without permission") { summariseFolderWithPermission(false) } .disabled(folderUrl == nil) } .padding() .fileImporter( isPresented: $showFolderPicker, allowedContentTypes: [UTType.init("public.folder")!], allowsMultipleSelection: false ) { result in switch result { case .success(let urls): if let selectedUrl = urls.first { print("Processing folder: \(selectedUrl)") processFolderURL(selectedUrl) } case .failure(let error): print("\(error.localizedDescription)") } } .onAppear() { guard folderUrl == nil else { return } retrieveFolderURL() } } func processFolderURL(_ selectedUrl: URL?) { guard selectedUrl != nil else { return } // Create and save a security scoped bookmark in AppStorage do { guard selectedUrl!.startAccessingSecurityScopedResource() else { print("Unable to access \(selectedUrl!)"); return } // Save bookmark bookmarkData = try selectedUrl!.bookmarkData(options: .minimalBookmark, includingResourceValuesForKeys: nil, relativeTo: nil) selectedUrl!.stopAccessingSecurityScopedResource() } catch { print("Unable to save security scoped bookmark") } folderUrl = selectedUrl! } func retrieveFolderURL() { guard let bookmarkData = bookmarkData else { print("No bookmark data available") return } do { var isStale = false let url = try URL( resolvingBookmarkData: bookmarkData, options: .withoutUI, relativeTo: nil, bookmarkDataIsStale: &isStale ) folderUrl = url } catch { print("Error accessing URL: \(error.localizedDescription)") } } func summariseFolderWithPermission(_ permission: Bool) { folderReport = nil print(String(describing: folderUrl)) guard folderUrl != nil else { return } if permission { print("Result of access requrest is \(folderUrl!.startAccessingSecurityScopedResource())") } do { let contents = try FileManager.default.contentsOfDirectory(atPath: folderUrl!.path) folderReport = "\(contents.count) files, the first is: \(contents.first!)" } catch { print(error.localizedDescription) } if permission { folderUrl!.stopAccessingSecurityScopedResource() } } }

A user of my app reported that when trying to remove a file it always fails with the error "file couldn't be removed because you don't have permission to access it (Cocoa Error Domain 513)". After some testing, we found out that it's caused by trying to delete non-empty directories. I'm using FileManager.removeItem(atPath:) which has worked fine for many years, but it seems that with their particular NAS, it doesn't work. I could work around this by checking if the file is a directory, and if it is, enumerating the directory and remove each contained file before removing the directory itself. But shouldn't this already be taken care of? In the source code of FileManager I see that for Darwin platforms it calls removefile(pathPtr, state, removefile_flags_t(REMOVEFILE_RECURSIVE)) so it seems that it should already work. Is the REMOVEFILE_RECURSIVE flag perhaps ignored by the device? But then, is the misleading "you don't have permission to access the file" error thrown by the device or by macOS? For the FileManager source code, see https://github.com/swiftlang/swift-foundation/blob/1d5d70997410fc8b7700c8648b10d6fc28194202/Sources/FoundationEssentials/FileManager/FileOperations.swift#L444

I've faced with some performance issues developing my readonly filesystem using fskit. For below screenshot: enumerateDirectory returns two hardcoded items, compiled with release config 3000 readdirsync are done from nodejs. macos 15.5 (24F74) I see that getdirentries syscall takes avg 121us. Because all other variables are minimised, it seems like it's fskit<->kernel overhead. This itself seems like a big number. I need to compare it with fuse though to be sure. But what fuse has and fskit seams don't (I checked every page in fskit docs) is kernel caching. Fuse supports: caching lookups (entry_timeout) negative lookups (entry_timeout) attributes (attr_timeout) readdir (via opendir cache_readdir and keep_cache) read and write ops but thats another topic. And afaik it works for both readonly and read-write file systems, because kernel can assume (if client is providing this) that cache is valid until kernel do write operations on corresponding inodes (create, setattr, write, etc). Questions are: is 100+us reasonable overhead for fskit? is there any way to do caching by kernel. If not currently, any plans to implement? Also, additional performance optimisation could be done by providing lower level api when we can operate with raw inodes (Uint64), this will eliminate overhead from storing, removing and retrieving FSItems in hashmap.

I have a simple impossible task, to restore /var/root/Library/Application Support/multipassd/qemu/vault/instances/gcc-cobol/ubuntu-22.04-server-cloudimg-arm64.img as of 8:02 Saturday morning. Because /var/root is owned by, well, root, the usual techniques don't work. This is a VM image hosted by qemu via Canonical's Multipass. ISTM the strategy would be to first mount the NAS filesystem and then use tmutil(8) to list the backups and recover the file. But $ sudo mount -v -o rdonly -t smb //nasa.local/TimeMachine /usr/local/mnt/ mount: exec /Library/Filesystems/smb.fs/Contents/Resources/mount_smb for /usr/local/mnt: No such file or directory mount: /usr/local/mnt failed with 72 Must I defeat SIP to do this?