General:
Forums subtopic: App & System Services > Core OS
Forums tags: Files and Storage, Foundation, FSKit, File Provider, Finder Sync, Disk Arbitration, APFS
Foundation > Files and Data Persistence documentation
Low-level file system APIs are documented in UNIX manual pages
File System Programming Guide archived documentation
About Apple File System documentation
Apple File System Guide archived documentation
File system changes introduced in iOS 17 forums post
On File System Permissions forums post
Extended Attributes and Zip Archives forums post
Unpacking Apple Archives forums post
Creating new file systems:
FSKit framework documentation
File Provider framework documentation
Finder Sync framework documentation
App Extension Programming Guide > App Extension Types > Finder Sync archived documentation
Managing storage:
Disk Arbitration framework documentation
Disk Arbitration Programming Guide archived documentation
Mass Storage Device Driver Programming Guide archived documentation
Device File Access Guide for Storage Devices archived documentation
BlockStorageDeviceDriverKit framework documentation
Volume format references:
Apple File System Reference
TN1150 HFS Plus Volume Format
Share and Enjoy
—
Quinn “The Eskimo!” @ Developer Technical Support @ Apple
let myEmail = "eskimo" + "1" + "@" + "apple.com"
File Provider
RSS for tagAllow other apps to access the documents and directories stored and managed by your containing app using File Provider.
Posts under File Provider tag
57 Posts
Selecting any option will automatically load the page
Post
Replies
Boosts
Views
Activity
I want to use FileProvder to implement the function of recovering from the recycle bin (the cloud recycle bin does not move, and after the local recycle bin is restored, the upload event is triggered again), but testing shows that the current recovery from the recycle bin is through the modifyItem event, and the CreateItem event is not triggered again to upload locally restored files
Implement the deletion of undelivered files (dateless) without moving them to the recycle bin, which currently appears to be achieved by granting file. dash permission. But it is possible for the content of a file to be manually verified by the user. How can this be solved? How can we dynamically monitor whether a file is dataless
Thank you for your reply. Could you please help answer my question
I face this issue only on macOS 26 and only on the Intel architecture.
I'm unable to download files from a file provider's folder when I make them read-only.
STEPS TO REPRODUCE
Download the sample from https://developer.apple.com/documentation/fileprovider/synchronizing-files-using-file-provider-extensions?language=objc
Follow the steps on the page to configure the project.
Build the project.
Run it.
Add a domain.
Open the domain's folder in the Finder.
Move a file to the domain's folder.
Right-click on the file in the domain's folder and select "Remove Download".
Close the Finder's window with the domain's folder and kill all the "Provider" processes to get rid of running instances of the extension.
Change Item's capabilities in Item.swift to make the items read-only:
var result: NSFileProviderItemCapabilities = [
.allowsContentEnumerating,
.allowsReading
]
Rebuild the project and run it.
Open the domain's folder and try to drag and drop the file from the extension's folder to, let's say, the Desktop folder.
EXPECTED RESULT
The file is copied
ACTUAL RESULT
A dialog pops up with text "The file “filename” cannot be downloaded. Do you want to skip it?" Stop/Skip
We use File Provider Extension in our main app, and it is working fine.
We always call "NSFileProviderManager.add(_:completionHandler:)" function to start the extension, and "NSFileProviderManager.disconnect(reason:options:completionHandler:)" to temporarily quit the extension with the reason which will be shown in the Finder at the top of the FP domain folder.
But sometimes, when the main app calls the above functions, the following issue cases occur, and the extension does not start/stop:
The completionHandler function doesn't get called (As we noticed, we waited for 2 minutes. Then, we restarted the main app.)
One of the following errors returned: i) "The application cannot be used right now", ii) "Couldn't communicate with the helper application", iii) "No valid file provider found with identifier"
Here, the important thing is that restarting the main app once or twice clears the issue, and the extension starts.
But it is frustrating to restart the app each time we get this issue.
We want to know the following things:
Why and when do the above issues occur?
Why do they occur only sometimes, and how does the app restart clear the issue?
How do we resolve them without restarting the main app?
This has become a critical issue, so a detailed explanation would be greatly appreciated. TIA.
Topic:
App & System Services
SubTopic:
Core OS
Tags:
Files and Storage
Extensions
macOS
File Provider
We are creating a Replicated FileProvider based application, where we need to change folder icons for root level folders.
I tried below two approaches.
This using NSFileProviderDecorations + Custom UTType, this changed the UI as shown:
This using Custom UTType, this had no UI change:
How can we change the default folder icon, to our custom icon?
I want to implement a feature on macOS using FileProvider: only grant the allowsTrashing permission to files that have already been downloaded, while not granting it to dataless files. However, the system will automatically drain and clear the content. How can this be detected (and how to determine whether a file is dataless)
I want to traverse my local Google Drive folder to calculate the size of all the files on my drive.
I'm not interested in files or directories that are not present locally.
I use getattrlistbulk for traversing and it takes way too much time. I think it is because FileProvider tries to download metadata for the directories that are not yet materialised.
Is there a way to skip non-materialised directories?
https://developer.apple.com/documentation/fileprovider/nsfileproviderpartialcontentfetching/3923718-fetchpartialcontents
fetchPartialContents(for:version:request:minimalRange:aligningTo:options:completionHandler:)
I need to use this function to fetch contents of the files partially. But it seems I'm just unable to receive any callback when i try to open the file via double click on finder.
I've tried to open files of different types and sizes but still i'm defaulting back to fetchContents(for:version:request:completionHandler:) .
I've been thinking if there are any specific configurations or requirements that i have to meet , so i could trigger this callback function for all the fetch Operations for files ?
If No, then where am i going wrong ?
In the context of a NSFileProviderReplicatedExtension I would like to only see the "Move to Bin" Finder action when files have been materlialised ( isDownloaded fileprovider attribute )
I thought it might be possible to get the isDownloaded attribute in my NSFileProviderItemProtocol class capabilities method but that doesn't seem to be the case.
Possible ?
Hello,
we have a file provider based macOS app. Around June we started receiving reports that our users have problems when opening files. Sometimes they get "Invalid argument" alerts
after double-clicking on a dataless file. We receive similar errors when trying to materialize the files programmatically from our app (not FP extension)(*):
"The operation could not be completed. Invalid argument"
code: 22
domain: "NSPOSIXErrorDomain"
underlyingError:
"cannotMaterialize"
code: 33
domain: "libfssync.VFSFileError"
We also see those errors with matching timestamps in the output from fileproviderctl dump:
> (...) update-item: 🔶 last:(...) (-1min27s) (...) error:'NSError: POSIX 22 "The operation couldn’t be completed. Invalid argument" Underlying={NSError: libfssync.VFSFileError 33 "cannotMaterialize" }}' domain:none category:<nil> (...)
At the same time our file provider extension receives fetchPartialContents call or no call at all. If it receives the call it finishes with success and returns correct range:
requestedRange: "{0, 15295}"
returnedRange: "{0, 524288}"
alignment: "16384"
Sadly we don't know how to reproduce those issues. We will be grateful for any hints that could be useful in debugging.
Some more context:
if materializing a file fails with this error, subsequent materialization attempts fail similarly
in local testing when downloading a file with the code below, or double-click, we only get regular fetchContents call
file returned by fetchPartialContents should have correct size
the app is built with XCode 16.1, customers reporting this issue have OS/FP versions: 24F74/2882.120.74 and 24G90/2882.140.30
(*) More or less the code that we use to materialize files
func materializeURL(_ url: URL) throws {
if try url.isDataless() {
var error: NSError? = nil
let coordinator = NSFileCoordinator(filePresenter: nil)
coordinator.coordinate(readingItemAt: url, error: &error) { _ in }
if let error {
throw error
}
}
}
private extension URL {
func isDataless() throws -> Bool {
let downloadStatus = try self
.resourceValues(forKeys: [.ubiquitousItemDownloadingStatusKey])
.ubiquitousItemDownloadingStatus
return downloadStatus == .notDownloaded || downloadStatus == .none
}
}
I’ve filed this as FB20943098 (macOS 26.1 – FileProvider v3 synchronous enumeration bug), but posting here in case others can reproduce and add duplicates.
Systems:
macOS 26.1 (26B82)
M4 Mac mini Pro and M4 MacBook Air
Symptoms:
In any app (TextEdit, Pages, Browsers, etc.), the Open/Save dialog lags for ~1s per folder navigation click. CPU spikes from fileproviderd, cloudd, bird, and siriactionsd.
Key discovery:
If my iCloud Drive root is empty (only “Documents” and “Downloads”), performance is perfect.
As soon as any folder or file exists at the root of iCloud Drive, the lag returns immediately.
Moving those items into “Documents” or “Downloads” makes everything smooth again.
Analysis:
Based on process traces and container paths, this appears to originate in the FileProvider.framework subsystem (via fileproviderd), which mediates iCloud Drive. Early evidence suggests that folder enumeration of the iCloud Drive container root may be blocking UI threads in macOS 26.1. I believe this may be related to the recent internal migration of the file-provider backend (often referred to as “v3”), but I do not have direct confirmation from Apple of that exact change.
MacOS 26.1’s new FileProvider v3 backend seems to be blocking the Open/Save panel while enumerating the iCloud Drive root container (~/Library/Application Support/FileProvider/723EBBFF-…).
Folder enumeration seems to wait synchronously for metadata from fileproviderd, and if the local SQLite DB is busy (WAL writes or sync state checks), UI freezes briefly.
Workarounds:
Disabling iCloud Drive entirely fixes the issue.
Simply disabling Desktop/Documents sync does not help.
Keeping the iCloud Drive root empty avoids the lag without turning iCloud off.
I am able to store whatever I please in the Desktop or Documents folder which is currently syncing.
Would appreciate if others on 26.1 could confirm.
Engineers: I’ve attached fs_usage, log stream, and process samples to my Feedback ticket via the FB20943098.
Expected behavior: Folder enumeration in NSOpenPanel should remain asynchronous regardless of FileProvider background activity. Open/save modal should be responsive and smooth.
I'm working on an iOS document-based app. It uses ReferenceFileDocument and custom creation of documents via DocumentGroupLaunchScene + NewDocumentButton. It works fine when I use the plain NewDocumentButton("Whatever") (without any more arguments), but when I want to perform additional setup via preapreDocumentURL or even just add a contentType it gives such output in the console when I hit it:
Content serialization failed, document won't be saved.
UTType.replayable is correctly wired up in the plist.
It looks like a bug in the SDK, but maybe there is a chance that I'm doing something wrong?
Here's a code:
import SwiftUI
import UniformTypeIdentifiers
import Combine
@main
struct MyApp: App {
var body: some Scene {
DocumentGroup {
Document()
} editor: { documentConfiguration in
EmptyView()
}
DocumentGroupLaunchScene("Yoyo") {
NewDocumentButton(contentType: .replayable) {
return URL(string: "whatever, it doesnt even go there...")!
}
}
}
}
final class Document: ReferenceFileDocument {
static var readableContentTypes: [UTType] { [.replayable] }
@Published var x = 0
init() {}
init(configuration: ReadConfiguration) throws {}
func snapshot(contentType: UTType) throws -> Data {
Data()
}
func fileWrapper(snapshot: Data, configuration: WriteConfiguration) throws -> FileWrapper {
.init(regularFileWithContents: snapshot)
}
}
extension UTType {
static var replayable: UTType {
UTType(exportedAs: "com.whatever.yo")
}
}
Topic:
UI Frameworks
SubTopic:
SwiftUI
Tags:
Files and Storage
File Provider
SwiftUI
Uniform Type Identifiers
In the context of a FPUIActionExtensionViewController module the prepare method is defined like this:
override func prepare(forAction actionIdentifier: String,
itemIdentifiers: [NSFileProviderItemIdentifier]) {
So you would expect the itemIdentifiers list to be the item identifier but instead it is a list of the internal fileprovider IDs like: __fp/fs/docID(6595461)
So this is a bit problematic because the only way to recover the ID is by using getUserVisibleURL to get the path which is not great.
Is there a better way ?
Am I missing something ?
Thanks,
Hi, Is it possible to create an App in USB portable flash drive, which can automatically call iPhone file app, to allow iPhone file app access the content of flash drive, when USB portable flash plug into iPhone?
Topic:
App & System Services
SubTopic:
Core OS
Tags:
File Provider
Multipeer Connectivity
Media Accessibility
I am writing an NSFileProviderReplicatedExtension for my app. Every once in a while it will get to a point where
NSFileProviderManager.getDomainsWithCompletionHandler { domains, error in
DispatchQueue.main.async {
if let error = error {
completion(.failure(.domainQueryFailed(error)))
} else {
completion(.success(domains))
}
}
}
this always fails, once this happens then regardless of what I do - clean build, restart machine, uninstall plugin nothing works. The only way to get back to a wokring state is a full reinstall of the OS. It seems like when this happens Finder gets to a weird irrecoverable state that only a restart can fix. When it fails the error is always :
The application cannot be used right now.
the only way out is reisntall the OS. When this happened last time, I was advised to the use the debugging profile: https://developer.apple.com/forums/thread/797053 I now have that and have the log which is 300MB file, where do I upload it to? My machine is in that state, is there anything else I can run or diagnose to address this?
I have an iOS and macOS app that includes a file provider extension. on macOS is is perfect no issues anywhere.
on iOS it works for small datasets or if I do read only operations. as soon as I try to do anything with larger files I quickly hit the 20MB limit. I have solved file transfers by using chunking but when it comes to listing a folder with a couple thousand files it instantly crashes the FPE with an OOM error. works ok up to 100 files but anything beyond that crashes. I know enumerate items supports batches however the initial load form say a webdav server that has no concept of pagination will always fail to load in pieces no matter what I do. This likely explains why WebDAV was never implemented on iOS. in any case can you possibly consider upgrading the memory limit for FPE's or provide some mechanism to call our full iOS app for more processing power in the background to handle requests on demand? I do not understand where 20MB is a reasonable number. even 100MB seems more reasonable with everything have much more memory these days this seems incredibly limiting. even an option to request increased memory with a capability would be fine but that only works for the app itself not the FPE target. please advise if there is anything that can be done.
I am writing an NSFileProviderExtension for my app. Every once in a while it will get to a point where
NSFileProviderManager.getDomainsWithCompletionHandler { domains, error in
DispatchQueue.main.async {
if let error = error {
completion(.failure(.domainQueryFailed(error)))
} else {
completion(.success(domains))
}
}
}
this always fails, once this happens then regardless of what I do - clean build, restart machine, uninstall plugin nothing works. The only way to get back to a wokring state is a full reinstall of the OS. It seems like when this happens Finder gets to a weird irrecoverable state that only a restart can fix.
Is there anything I can do to address this? I have a laptop which is in this state. Finder has this image attached
We are creating a Replicated FileProvider based application, where we want to handle different types of errors. As per doc: https://developer.apple.com/documentation/fileprovider/synchronizing-files-using-file-provider-extensions?language=objc#Handle-errors-elegantly
NSFileProviderErrorNotAuthenticated is a resolvable error, and once we report it, the system throttles the sync operation until something (most likely the app or extension) calls signalErrorResolved(:completionHandler:) to signal that the user or the server resolves the error.
But this is not happening in our app, see below the sample code snippet (showing just error related code to keep it concise):
NSProgress* MacFileProvider::modifyItem(....) {
NSProgress *nsProgress = [[NSProgress alloc] init];
nsProgress.totalUnitCount = NSURLSessionTransferSizeUnknown;
NSError *error = [NSError errorWithDomain:NSFileProviderErrorDomain
code:NSFileProviderErrorNotAuthenticated
userInfo:nil];
completionHandler(nil, 0, false, error);
return nsProgress;
}
Observed behaviour:
On making local edits to a file, though this function returns resolvable error, this function is being called multiple times with retry back-off interval. Also, this function is called when we edit other files as well.
Expected behaviour:
As we are returning resolvable error, system should have throttled the operation until we resolve the error. So, all sync operation should have stopped for any item.
Can someone please help understand this behaviour difference, and how to achieve the expected behaviour.
I am building a Vision OS app that includes a File Provider and File Provider UI extension. Both work great in simulator.
When uploading to TestFlight, this message is shown:
Unsupported Platform. The extension bundle [...]/PlugIns/File ProviderUI.appex is not supported for this platform.
If I exclude the File Provider UI extension from the build, it is accepted. If I even include a hello-world File Provider UI extension, the error shown above is returned by ASC.
There is contradicting documentation on this subject:
https://developer.apple.com/documentation/technologyoverviews/app-extensions states that File Provider UI extension is not supported on Vision OS, so that explains ASC behavior
https://developer.apple.com/documentation/FileProviderUI (and all other framework docs) states that File Provider UI extension is supported on Vision OS, so that explains why it works on simulator.
Now, which of these two is correct?
My best guess at this point is that ASC's logic follows the first document linked above, while the OS and framework actually follow the second.
The same discrepancy seems to hold for macOS, but I'm currently focusing on Vision OS.
Ideas? Anybody using a File Provider UI extension on Vision OS?
I'm using UIDocumentPickerViewController to open a url. Works fine in debug mode but version on the App Store is failing.
Code to create the document picker is like:
NSArray *theTypes = [UTType typesWithTag:@"docxtensionhere" tagClass:UTTagClassFilenameExtension conformingToType:nil];
UIDocumentPickerViewController *documentPicker = [[UIDocumentPickerViewController alloc]initForOpeningContentTypes:theTypes];
documentPicker.delegate = self;
[self presentViewController:documentPicker animated:YES completion:nil];
So in debug mode this is all gravy. -documentPicker:didPickDocumentsAtURLs: passes back a URL and I can read the file.
In release mode I get a URL but my app is denied access to read the file. After inspecting some logging it appears the sandbox is not granting my app permission.
error Domain=NSCocoaErrorDomain Code=257 "The file “Filename.fileextensionhere” couldn’t be opened because you don’t have permission to view it." UserInfo={NSFilePath=/private/var/mobile/Library/Mobile Documents/comappleCloudDocs/Filename.fileextensionhere, NSUnderlyingError=0x2834c9da0 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}
--
If I'm doing something wrong with UIDocumentPickerViewController it is a real shame that permission is not being denied in Debug mode, as devs are more likely to catch in prior to release. Anyone know where I'm going wrong and if not have a workaround? Thanks in advance.
This concerns file provider framework on macOS.
Some users of our application (Egnyte.app) report that they have problems downloading dataless files.
When a file reaches invalid state, trying to open or download it through Finder results in "Invalid argument" alert (see example-recording.mp4).
At the same time our FileProvider extension receives no fetchContents or fetchPartialContents calls.
A step-by-step set of instructions to reproduce the problem (if possible)
So far we don't have clear reproduction steps.
The issue is easily reproducible, for multiple files, for some of our customers.
See attached sysdiagnose and recording.
What results you expected
Our extension receives a request to download the file.
File downloads and opens successfully.
What results you actually saw
No download request made to our File Provider extension.
File doesn't open, Finder alert instead.
PLEASE NOTE:
Before recording and collecting sysdiagnose we installed FileProvider.mobileconfig, slightly modified official profile that we attach.
Example reproduction happens 8:33 into full-recording.mp4, around 17:01:18 / 17:01:19 machine’s time.
Shared sysdiagnose and recordings come from one of our customers, they permitted us to share the data.
In the recording they try to open files with multiple 3rd party applications (Vectorworx, Office PowerPoint) and those opens fail with alerts from those applications. We have similar reports from customers using Adobe apps.
More info in FB19462434