objcjs-types 0.4.0 → 0.5.0

package/dist/FileProvider/NSFileProviderErrorCode.d.ts

@@ -0,0 +1,27 @@
+export declare const NSFileProviderErrorCode: {
+    readonly NSFileProviderErrorNotAuthenticated: -1000;
+    readonly NSFileProviderErrorFilenameCollision: -1001;
+    readonly NSFileProviderErrorSyncAnchorExpired: -1002;
+    readonly NSFileProviderErrorPageExpired: -1002;
+    readonly NSFileProviderErrorInsufficientQuota: -1003;
+    readonly NSFileProviderErrorServerUnreachable: -1004;
+    readonly NSFileProviderErrorNoSuchItem: -1005;
+    readonly NSFileProviderErrorDeletionRejected: -1006;
+    readonly NSFileProviderErrorDirectoryNotEmpty: -1007;
+    readonly NSFileProviderErrorProviderNotFound: -2001;
+    readonly NSFileProviderErrorProviderTranslocated: -2002;
+    readonly NSFileProviderErrorOlderExtensionVersionRunning: -2003;
+    readonly NSFileProviderErrorNewerExtensionVersionFound: -2004;
+    readonly NSFileProviderErrorCannotSynchronize: -2005;
+    readonly NSFileProviderErrorNonEvictableChildren: -2006;
+    readonly NSFileProviderErrorUnsyncedEdits: -2007;
+    readonly NSFileProviderErrorNonEvictable: -2008;
+    readonly NSFileProviderErrorVersionNoLongerAvailable: -2009;
+    readonly NSFileProviderErrorExcludedFromSync: -2010;
+    readonly NSFileProviderErrorDomainDisabled: -2011;
+    readonly NSFileProviderErrorProviderDomainTemporarilyUnavailable: -2012;
+    readonly NSFileProviderErrorProviderDomainNotFound: -2013;
+    readonly NSFileProviderErrorApplicationExtensionNotFound: -2014;
+    readonly NSFileProviderErrorLocalVersionConflictingWithServer: -2015;
+};
+export type NSFileProviderErrorCode = typeof NSFileProviderErrorCode[keyof typeof NSFileProviderErrorCode];

package/dist/FileProvider/NSFileProviderErrorCode.js

@@ -0,0 +1,27 @@
+// AUTO-GENERATED by objcjs-types generator — DO NOT EDIT
+export const NSFileProviderErrorCode = {
+    NSFileProviderErrorNotAuthenticated: -1000,
+    NSFileProviderErrorFilenameCollision: -1001,
+    NSFileProviderErrorSyncAnchorExpired: -1002,
+    NSFileProviderErrorPageExpired: -1002,
+    NSFileProviderErrorInsufficientQuota: -1003,
+    NSFileProviderErrorServerUnreachable: -1004,
+    NSFileProviderErrorNoSuchItem: -1005,
+    NSFileProviderErrorDeletionRejected: -1006,
+    NSFileProviderErrorDirectoryNotEmpty: -1007,
+    NSFileProviderErrorProviderNotFound: -2001,
+    NSFileProviderErrorProviderTranslocated: -2002,
+    NSFileProviderErrorOlderExtensionVersionRunning: -2003,
+    NSFileProviderErrorNewerExtensionVersionFound: -2004,
+    NSFileProviderErrorCannotSynchronize: -2005,
+    NSFileProviderErrorNonEvictableChildren: -2006,
+    NSFileProviderErrorUnsyncedEdits: -2007,
+    NSFileProviderErrorNonEvictable: -2008,
+    NSFileProviderErrorVersionNoLongerAvailable: -2009,
+    NSFileProviderErrorExcludedFromSync: -2010,
+    NSFileProviderErrorDomainDisabled: -2011,
+    NSFileProviderErrorProviderDomainTemporarilyUnavailable: -2012,
+    NSFileProviderErrorProviderDomainNotFound: -2013,
+    NSFileProviderErrorApplicationExtensionNotFound: -2014,
+    NSFileProviderErrorLocalVersionConflictingWithServer: -2015,
+};

package/dist/FileProvider/NSFileProviderExtension.d.ts

@@ -3,6 +3,7 @@ import type { _NSArray } from "../Foundation/NSArray.js";
 import type { _NSData } from "../Foundation/NSData.js";
 import type { _NSDate } from "../Foundation/NSDate.js";
 import type { _NSDictionary } from "../Foundation/NSDictionary.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSNumber } from "../Foundation/NSNumber.js";
 import type { _NSObject } from "../Foundation/NSObject.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
@@ -35,11 +36,11 @@ export declare class _NSFileProviderExtension extends _NSObject {
     /**
      * This method is called when a placeholder URL should be provided for the item at the given URL. The implementation of this method should call +[NSFileProviderManager writePlaceholderAtURL:withMetadata:error:] with the URL returned by +[NSFileProviderManager placeholderURLForURL:], then call the completion handler.
      */
-    providePlaceholderAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject | null): void;
+    providePlaceholderAtURL$completionHandler$(url: _NSURL, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Should ensure that the actual file is in the position returned by URLForItemWithPersistentIdentifier:, then call the completion handler.
      */
-    startProvidingItemAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject | null): void;
+    startProvidingItemAtURL$completionHandler$(url: _NSURL, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Called after the last claim to the file has been released. At this point, it is safe for the file provider to remove the content file. Care should be taken that the corresponding placeholder file stays behind after the content file has been deleted.
      */
@@ -56,47 +57,47 @@ export declare class _NSFileProviderExtension extends _NSObject {
     /**
      * Import a document. The file or package at fileURL should be moved on disk into the file provider's own storage, where it will later be uploaded. The completion block should be executed after the move on disk, but before the upload. Before doing any network, actually. In the completion block, importedDocumentItem should have these properties set: - itemIdentifier - parentItemIdentifier (to the value passed in to this method) - filename (to fileURL's resource value for key NSURLNameKey) - creationDate (to NSURLCreationDateKey) - contentModificationDate (to NSURLContentModificationDateKey) - contentType (to NSURLContentTypeKey) - documentSize (to NSURLTotalFileSizeKey on a flat file, or to the sum of the files sizes for a package) - capabilities [fileURL startAccessingSecurityScopedResource] needs to be called prior to accessing this security scoped URL, and stopAccessingSecurityScopedResource needs to be called when done. Note that itemIdentifier should be set with no network call. It doesn't have to be the final identifier. If the identifier changes after talking to the server then the file provider should send a delete for the temporary, local identifier immediately followed by an add with the final identifier. A reasonable way of organizing files in the file provider storage is: <file provider storage path>/<itemIdentifier>/<filename>.<extension> If the item identifier was to change, you should move the file on disk to update its path, under coordination with NSFileCoordinatorWritingForMoving. This is expected to work offline even if there might be a collision (another item with the same filename and parentItemIdentifier) only detected when later syncing up this change to the server. In that case, it is suggested that a follow up update to the item change its filename to something unique. This wouldn't be considered an error to import. If however you can tell right away, with no communication to your server, that there is a collision then this call should fail with error code NSFileProviderErrorFilenameCollision generated with this method: -[NSError (NSFileProviderError) fileProviderErrorForCollisionWithItem:]. The existing item set in this error will be used to handle the collision, and ask the user if she or he would like to replace the existing item. This takes into account the existing item's capabilities (particularly NSFileProviderItemCapabilitiesAllowsTrashing and AllowsDeleting.) Collision checks should be case insensitive even if the filesystem or file provider might allow two coexisting filenames differing only by their case. Upload errors (such as NSFileProviderErrorInsufficientQuota) should be handled with a subsequent update to the item, setting its uploadingError property. Upload errors should not prevent creating or importing a document, because they can be resolved at a later date (for example, when the user has quota again.) Other errors will be presented to the user, but are unexpected. If you want to prevent imports in a given directory, then the directory item's capacities should exclude NSFileProviderItemCapabilitiesAllowsAddingSubItems.
      */
-    importDocumentAtURL$toParentItemIdentifier$completionHandler$(fileURL: _NSURL, parentItemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    importDocumentAtURL$toParentItemIdentifier$completionHandler$(fileURL: _NSURL, parentItemIdentifier: _NSString, completionHandler: ((importedDocumentItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Create a directory. This is expected to complete before doing any network. In the completion block, createdDirectoryItem should have these properties set: - itemIdentifier - parentItemIdentifier (to the value passed in to this method) - filename (to directoryName) - creationDate (to the current date and time) - contentType (to "public.folder" - UTTypeFolder) - childItemCount (to 0) - capabilities Errors (including collision errors) are handled as documented for the import method above. Directory creation is gated by the capabilities of the destination directory, with NSFileProviderItemCapabilitiesAllowsAddingSubItems.
      */
-    createDirectoryWithName$inParentItemIdentifier$completionHandler$(directoryName: _NSString, parentItemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    createDirectoryWithName$inParentItemIdentifier$completionHandler$(directoryName: _NSString, parentItemIdentifier: _NSString, completionHandler: ((createdDirectoryItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Rename a document or a directory. This is expected to complete before doing any network. itemName is the full file or directory name, complete with its file extension. In the completion block, property renamedItem.filename should change to itemName. Property renamedItem.displayName should also be updated if you chose to overwrite that method. Errors (including collision errors) are handled as documented for the import method above. Renames are gated by the capabilities of the renamed item, with NSFileProviderItemCapabilitiesAllowsRenaming.
      */
-    renameItemWithIdentifier$toName$completionHandler$(itemIdentifier: _NSString, itemName: _NSString, completionHandler: NobjcObject | null): void;
+    renameItemWithIdentifier$toName$completionHandler$(itemIdentifier: _NSString, itemName: _NSString, completionHandler: ((renamedItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Move an item to a new directory. This is expected to complete before doing any network. If newName is non null, the moved item should be renamed to newName. Errors (including collision errors) are handled as documented for the import method above. Moves are gated by the capabilities of both the moved item with NSFileProviderItemCapabilitiesAllowsReparenting, and the destination directory with NSFileProviderItemCapabilitiesAllowsAddingSubItems.
      */
-    reparentItemWithIdentifier$toParentItemWithIdentifier$newName$completionHandler$(itemIdentifier: _NSString, parentItemIdentifier: _NSString, newName: _NSString | null, completionHandler: NobjcObject | null): void;
+    reparentItemWithIdentifier$toParentItemWithIdentifier$newName$completionHandler$(itemIdentifier: _NSString, parentItemIdentifier: _NSString, newName: _NSString | null, completionHandler: ((reparentedItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Move an item to the trash. In the completion block, property trashedItem.isTrashed should be set to YES. You should keep track of the original parentItemIdentifier of the item before it was moved to trash, so you can move the item back where it used to be in the untrash method. You could use the trashedItem.parentItemIdentifier property for that. The trashed item should continue to belong to the working set of documents cached on the device and visible offline to the user. But if it is a directory, then all of its children should be removed from the working set and the file provider extension should send deletion events to make sure that they no longer appear in the recent lists. It is also suggested that shared documents be unshared when trashed. Trash is gated by the capabilities of the trashed item with NSFileProviderItemCapabilitiesAllowsTrashing.
      */
-    trashItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    trashItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: ((trashedItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Move an item out of the trash. If parentItemIdentifier is nil, the file provider should attempt to put the item back where it was when it was moved to the trash; otherwise it should move it to this new parent. If the item is a directory, then the file provider extension should enumerate the children and send addition events in the working set so that the documents in the now untrashed directory may be reindexed. Untrash is gated by the capabilities of the destination directory, with NSFileProviderItemCapabilitiesAllowsAddingSubItems.
      */
-    untrashItemWithIdentifier$toParentItemIdentifier$completionHandler$(itemIdentifier: _NSString, parentItemIdentifier: _NSString | null, completionHandler: NobjcObject | null): void;
+    untrashItemWithIdentifier$toParentItemIdentifier$completionHandler$(itemIdentifier: _NSString, parentItemIdentifier: _NSString | null, completionHandler: ((untrashedItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Delete an item forever. This is called when the user deletes an item that was already in the Trash and the item should no longer appear there after this call. This call should remove the item from the working set. Delete is gated by the capabilities of the removed item with NSFileProviderItemCapabilitiesAllowsDeleting.
      */
-    deleteItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    deleteItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Mark an item as recently used, or clear its lastUsedDate if nil. This last used date is the sort key for the recent lists. It is the primary hint that an item must belong to the working set cached and indexed on the user's device. The file provider is asked to persist the new last used date on disk, then call the completion callback with the updated last used date. At a later point, the file provider should sync the new last used date to their server. The error parameter is here for debugging purposes alone; it won't be presented to the user or otherwise handled, but it will be logged.
      */
-    setLastUsedDate$forItemIdentifier$completionHandler$(lastUsedDate: _NSDate | null, itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    setLastUsedDate$forItemIdentifier$completionHandler$(lastUsedDate: _NSDate | null, itemIdentifier: _NSString, completionHandler: ((recentlyUsedItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Tag an item, or untag it if tagData is nil. The file provider is asked to persist the new tag data on disk, then call the completion callback with the updated tagged data. At a later point, the file provider should sync the new tag data to their server. Tagged items are relevant to the user and should be in the working set even if they haven't been used recently. If set, the error will be immediately presented to the user and the item just won't be tagged. On shared items, tags should sync across the devices of any one participant but shouldn't sync across users.
      */
-    setTagData$forItemIdentifier$completionHandler$(tagData: _NSData | null, itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    setTagData$forItemIdentifier$completionHandler$(tagData: _NSData | null, itemIdentifier: _NSString, completionHandler: ((taggedItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * Mark a directory as favorite (or no longer favorite if favoriteRank is nil.) The favorite rank is used to represent the relative order of two favorite directories in the UI. It is a 64 bit unsigned integer. It needs to be synced. Favorite directories are relevant to the user and should be in the working set even if they haven't been used recently. The documents and directories in the favorite directory however don't all have to be in the working set, and don't all have to be made accessible offline. The file provider is asked to persist the new favorite rank on disk, then call the completion callback with the updated favorite rank. At a later point, the file provider should sync the new favorite rank to their server.
      */
-    setFavoriteRank$forItemIdentifier$completionHandler$(favoriteRank: _NSNumber | null, itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    setFavoriteRank$forItemIdentifier$completionHandler$(favoriteRank: _NSNumber | null, itemIdentifier: _NSString, completionHandler: ((favoriteItem: _NSFileProviderItem, error: _NSError) => void) | null): void;
     /**
      * The system calls this method to fetch thumbnails. The @p perThumbnailCompletionHandler should be called for each thumbnail, and @p completionHandler only after all the per thumbnail completion blocks. In the event of a global error, the implementation is allowed to skip calling the @p perThumbnailCompletionHandler for individual thumbnails. In that case, the @p completionHandler's error parameter would apply to all item identifiers for which @p perThumbnailCompletionHandler had not been called. If there is no thumbnail for a given item, the @p perThumbnailCompletionHandler should be called with its @p imageData and @p error parameters both set to nil. If the system decides that an in-flight thumbnail request is not needed anymore, it will call the returned @p NSProgress object's @p -cancel method, at which time the implementation should clean up any held resources. The system will cache the thumbnail for the item, and the cache will be invalidated when itemVersion.contentVersion changes.
      */
-    fetchThumbnailsForItemIdentifiers$requestedSize$perThumbnailCompletionHandler$completionHandler$(itemIdentifiers: _NSArray, size: CGSize, perThumbnailCompletionHandler: NobjcObject | null, completionHandler: NobjcObject | null): _NSProgress;
+    fetchThumbnailsForItemIdentifiers$requestedSize$perThumbnailCompletionHandler$completionHandler$(itemIdentifiers: _NSArray, size: CGSize, perThumbnailCompletionHandler: ((identifier: _NSString, imageData: _NSData, error: _NSError) => void) | null, completionHandler: ((error: _NSError) => void) | null): _NSProgress;
     /**
      * An identifier unique to this provider. When modifying the files stored in the directory returned by documentStorageURL, you should pass this identifier to your file coordinator's setPurposeIdentifier: method.
      * @deprecated NSFileProviderManager -providerIdentifier

package/dist/FileProvider/NSFileProviderExternalVolumeHandling.d.ts

@@ -1,7 +1,7 @@
-import type { NobjcObject } from "objc-js";
+import type { _NSError } from "../Foundation/NSError.js";
 export interface _NSFileProviderExternalVolumeHandling {
     /**
      * Implement this protocol on your extension's Principal Class in order for the system to ask your extension whether a domain located on an external volume should be connected. Your extension may use this method as an opportunity to check for, and setup if necessary, state to operate the extension. Such as prompting the user to login in your application. When creating domains on external drive, store state related to the domain in the `userInfo` parameter to `-[NSFileProviderDomain initWithDisplayName:userInfo:volumeURL:]`, such as the user's ID, to help your extension identify the domain when connected on other devices. This userInfo will be persisted on the external volume, and provided in the ReplicatedExtension initializer when the drive is connected to a new device. If your extension responds with an NSError, the domain will be in a disconnected state. Non-downloaded files in the domain will not be downloadable, and file edits will not be synced up. The system will display UI to inform the user. Your extension will be able to enumerate this domain in `+[NSFileProviderManager getDomainsWithCompletionHandler:]`, with the `-[NSFileProviderDomain disconnected]` property set as YES. If at a later point, the user has setup the necessary state to service requests for the disconnected external domain, your extension may call `-[NSFileProviderManager reconnectWithCompletionHandler:]`. If your extension does not implement this protocol, domains on external volumes will automatically be connected and instantiated in your extension.
      */
-    shouldConnectExternalDomainWithCompletionHandler$?(completionHandler: NobjcObject | null): void;
+    shouldConnectExternalDomainWithCompletionHandler$?(completionHandler: ((connectionError: _NSError) => void) | null): void;
 }

package/dist/FileProvider/NSFileProviderIncrementalContentFetching.d.ts

@@ -1,12 +1,13 @@
-import type { NobjcObject } from "objc-js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
 import type { _NSString } from "../Foundation/NSString.js";
 import type { _NSURL } from "../Foundation/NSURL.js";
+import type { _NSFileProviderItem } from "./NSFileProviderItem.js";
 import type { _NSFileProviderItemVersion } from "./NSFileProviderItemVersion.js";
 import type { _NSFileProviderRequest } from "./NSFileProviderRequest.js";
 export interface _NSFileProviderIncrementalContentFetching {
     /**
      * Update a previously provided item to a new version. If the system already has a version of an item and learns that a new version is available, it may call this method to update the existing version to a new version. The semantics of the requestedVersion parameter are the same as for the non-delta update method above.
      */
-    fetchContentsForItemWithIdentifier$version$usingExistingContentsAtURL$existingVersion$request$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion | null, existingContents: _NSURL, existingVersion: _NSFileProviderItemVersion, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    fetchContentsForItemWithIdentifier$version$usingExistingContentsAtURL$existingVersion$request$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion | null, existingContents: _NSURL, existingVersion: _NSFileProviderItemVersion, request: _NSFileProviderRequest, completionHandler: ((fileContents: _NSURL, item: _NSFileProviderItem, error: _NSError) => void) | null): _NSProgress;
 }

package/dist/FileProvider/NSFileProviderKnownFolderSupporting.d.ts

@@ -1,8 +1,9 @@
-import type { NobjcObject } from "objc-js";
+import type { _NSFileProviderKnownFolderLocations } from "./NSFileProviderKnownFolderLocations.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { NSFileProviderKnownFolders } from "./NSFileProviderKnownFolders.js";
 export interface _NSFileProviderKnownFolderSupporting {
     /**
      * Request suitable locations for known folders. This function is called when the user decides to switch some known folders to the current domain, outside of the `claimKnownFolders` call. The system provides a list of folders that the user decides to move to this domain, and expect in return non-nil locations for those known folders.
      */
-    getKnownFolderLocations$completionHandler$?(knownFolders: NSFileProviderKnownFolders, completionHandler: NobjcObject | null): void;
+    getKnownFolderLocations$completionHandler$?(knownFolders: NSFileProviderKnownFolders, completionHandler: ((arg0: _NSFileProviderKnownFolderLocations, arg1: _NSError) => void) | null): void;
 }

package/dist/FileProvider/NSFileProviderManager.d.ts

@@ -2,6 +2,7 @@ import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "../Foundation/NSArray.js";
 import type { _NSDictionary } from "../Foundation/NSDictionary.js";
 import type { _NSError } from "../Foundation/NSError.js";
+import type { _NSFileProviderService } from "../Foundation/NSFileProviderService.js";
 import type { _NSObject } from "../Foundation/NSObject.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
 import type { _NSString } from "../Foundation/NSString.js";
@@ -15,6 +16,7 @@ import type { _NSFileProviderPendingSetEnumerator } from "./NSFileProviderPendin
 import type { NSRange } from "../structs/NSRange.js";
 import type { NSFileProviderServiceName } from "../Foundation/NSFileProviderServiceName.js";
 import type { NSProgressFileOperationKind } from "../Foundation/NSProgressFileOperationKind.js";
+import type { NSFileProviderDomainIdentifier } from "./NSFileProviderDomainIdentifier.js";
 import type { NSFileProviderDomainRemovalMode } from "./NSFileProviderDomainRemovalMode.js";
 import type { NSFileProviderItemFields } from "./NSFileProviderItemFields.js";
 import type { NSFileProviderKnownFolders } from "./NSFileProviderKnownFolders.js";
@@ -29,7 +31,7 @@ export declare class _NSFileProviderManager extends _NSObject {
     /**
      * Return the identifier and domain for a user visible URL. This method returns the identifier and domain of a user visible URL if applicable. Calling this method on a file which doesn't reside in your provider/domain, or which hasn't yet been assigned an identifier by the provider will return the Cocoa error NSFileNoSuchFileError.
      */
-    static getIdentifierForUserVisibleFileAtURL$completionHandler$(url: _NSURL, completionHandler: NobjcObject | null): void;
+    static getIdentifierForUserVisibleFileAtURL$completionHandler$(url: _NSURL, completionHandler: ((itemIdentifier: _NSString, domainIdentifier: NSFileProviderDomainIdentifier, error: _NSError) => void) | null): void;
     /**
      * Writes out a placeholder at the specified URL. The placeholder is used in place of the actual file for operations that do not require the file's actual data to be on disk: - if attributes are requested by an application via the getPromisedItemResourceValue: method on NSURL - or via a coordination with the NSFileCoordinatorReadingImmediatelyAvailableMetadataOnly flag set - to verify whether an application has access to a file Your extension should provide placeholders by implementing the providePlaceholderAtURL: method, but your application may choose to proactively write out placeholders to facilitate access to files. This is especially useful if your application wants to actively hand out a file URL, e.g. using UIActivityViewController, in which case it should ensure that either the file or a placeholder is present on disk first. The path of the placeholder is fixed and must be determined in advance by calling the placeholderURLForURL: method.
      */
@@ -41,19 +43,19 @@ export declare class _NSFileProviderManager extends _NSObject {
     /**
      * Register a domain in which items can be stored. If a domain with the same identifier already exists, `addDomain` will update the display name and hidden state of the domain and succeed. When the domain is backed by a NSFileProviderReplicatedExtension, the system will create a disk location where the domain will be replicated. If that location already exists on disk this call will fail with the code NSFileWriteFileExistsError.
      */
-    static addDomain$completionHandler$(domain: _NSFileProviderDomain, completionHandler: NobjcObject | null): void;
+    static addDomain$completionHandler$(domain: _NSFileProviderDomain, completionHandler: ((error: _NSError) => void) | null): void;
     /** Remove a domain. */
-    static removeDomain$completionHandler$(domain: _NSFileProviderDomain, completionHandler: NobjcObject | null): void;
+    static removeDomain$completionHandler$(domain: _NSFileProviderDomain, completionHandler: ((error: _NSError) => void) | null): void;
     /** Remove a domain with options */
-    static removeDomain$mode$completionHandler$(domain: _NSFileProviderDomain, mode: NSFileProviderDomainRemovalMode, completionHandler: NobjcObject | null): void;
+    static removeDomain$mode$completionHandler$(domain: _NSFileProviderDomain, mode: NSFileProviderDomainRemovalMode, completionHandler: ((_result: _NSURL, error: _NSError) => void) | null): void;
     /** Get all registered domains. */
-    static getDomainsWithCompletionHandler$(completionHandler: NobjcObject | null): void;
+    static getDomainsWithCompletionHandler$(completionHandler: ((domains: _NSArray, error: _NSError) => void) | null): void;
     /** Remove all registered domains. */
-    static removeAllDomainsWithCompletionHandler$(completionHandler: NobjcObject | null): void;
+    static removeAllDomainsWithCompletionHandler$(completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Request the creation of a new domain that will take ownership of on-disk data that were previously managed without a file provider. You can use this method in order to migrate from a software that managed a file hierarchy on disk to a NSFileProviderExtension without having to redownload the data that was already on disk. The URL is expected to point to a directory. That directory will be moved away, its ownership being taken by the system. From this point, your extension's createItemFromTemplate method will be called for every item found in the directory with the special NSFileProviderCreateItemMayAlreadyExist option. In case a domain with the same name already exists in the file provider manager, the call will fail with the code NSFileWriteFileExistsError. The URL will remain untouched. In case the system does not allow the extension to request a migration, the call will fail with NSFeatureUnsupportedError. In case of success, the URL will become invalid and the domain will be created. The completion handler is called as soon as the domain is created. Your provider will receive calls to createItemBasedOnTemplate afterward. When the import of the file hierarchy is finished, the system calls -[NSFileProviderExtension signalDidFinishImportingItemsFromDiskWithCompletionHandler:]. In case -[NSFileProviderManager reimportItemsBelowItemWithIdentifier:completionHandler:] is called before the end of the import, a single call to importDidFinishWithCompletionHandler will be received for both the import and the scan.
      */
-    static importDomain$fromDirectoryAtURL$completionHandler$(domain: _NSFileProviderDomain, url: _NSURL, completionHandler: NobjcObject | null): void;
+    static importDomain$fromDirectoryAtURL$completionHandler$(domain: _NSFileProviderDomain, url: _NSURL, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Check if a URL is eligible for storing a domain. This returns whether the check has been performed succesfully - NOT whether the drive is eligible. If an error was encountered while checking, this method returns FALSE and an error describing the problem will be set. The eligible parameter will contain the result of the check and indicate whether the volume can be used to store FP domains. Its value is only defined if the call returns YES. The url can be any existing and accessible URL on the volume for which you want to assess eligibility. The checks are volume-wide and the exact location on the volume doesn't impact them. If a drive is eligible, unsupportedReason will be empty (0). Otherwise it will contain the list of identified conditions that currently prevent this drive from being used to store FP domains.
      */
@@ -63,15 +65,15 @@ export declare class _NSFileProviderManager extends _NSObject {
     /**
      * Call this method either in the app or in the extension to trigger an enumeration, typically in response to a push. When using NSFileProviderExtension, the system will enumerate containers while the user is viewing them in the UI. If there are changes to the container while an enumerator is open, call this method with the identifier of that container. This will trigger another call to -[NSFileProviderEnumerator enumerateChangesForObserver:fromSyncAnchor:] on that enumerator, and the UI will be refreshed, giving the user live updates on the presented enumeration. If there are changes in the working set, call this method with containerItemIdentifier set to NSFileProviderWorkingSetContainerItemIdentifier, even if there is no live enumeration for the working set container. When using NSFileProviderReplicatedExtension, only call this method with NSFileProviderWorkingSetContainerItemIdentifier. Other container identifiers are ignored. The system will automatically propagate working set changes to the UI, without explicitly signaling the containers currently being viewed in the UI. In addition to using this method, your application/extension can register for pushes using the PKPushTypeFileProvider push type. Pushes of the form { "container-identifier": "<identifier>", "domain": "<domain identifier>" } with a topic of "<your application identifier>.pushkit.fileprovider" will be translated into a call to signalEnumeratorForContainerItemIdentifier:completionHandler:.
      */
-    signalEnumeratorForContainerItemIdentifier$completionHandler$(containerItemIdentifier: _NSString, completion: NobjcObject | null): void;
+    signalEnumeratorForContainerItemIdentifier$completionHandler$(containerItemIdentifier: _NSString, completion: ((error: _NSError) => void) | null): void;
     /**
      * Return the security scoped URL to the user visible location for an item identifier. The caller must use file coordination (see NSFileCoordinator) if it wishes to read the content or list the children of the URL. The caller should not try to manipulate files in the user visible location. All changes coming from the provider should go through updates in the working set that will be applied to the user visible items by the system. The location may differ from the logical parentURL/filename. If an item on disk cannot be assigned the requested name (e.g. because the local file system has different case collision rules from the provider), one of the items can be assigned a different local name. In that case, the "com.apple.fileprovider.before-bounce#PX" extended attribute will contain the filename before collision resolution. This attribute is only set if the item has been assigned a different local name following a collision. Such local names are not synced up to the provider; the purpose of the attribute is to enable consistency checkers to detect this case. Before accessing the content of the returned URL, the caller must call `-[NSURL startAccessingSecurityScopedResource] on the returned URL and call `-[NSURL stopAccessingSecurityScopedResource]` when done accessing the content. The returned URL grants read-write access to the user visible location for the corresponding item. On iOS, for replicated domains, the extension process will never be granted access to the user visible location, this function will always fail with `NSFileReadNoPermissionError`.
      */
-    getUserVisibleURLForItemIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    getUserVisibleURLForItemIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: ((userVisibleFile: _NSURL, error: _NSError) => void) | null): void;
     /**
      * Registers the given NSURLSessionTask to be responsible for the specified item. A given item can only have one task registered at a time. The task must be suspended at the time of calling. The task's progress is displayed on the item when the task is executed.
      */
-    registerURLSessionTask$forItemWithIdentifier$completionHandler$(task: _NSURLSessionTask, identifier: _NSString, completion: NobjcObject | null): void;
+    registerURLSessionTask$forItemWithIdentifier$completionHandler$(task: _NSURLSessionTask, identifier: _NSString, completion: ((error: _NSError) => void) | null): void;
     /**
      * A temporary directory suitable to store files that will be exchanged with the system. The returned URL is guaranteed to be on the same volume as the user visible URL, making sure the system can atomatically clone/move files from that location to the user visible URL. The provider can also use that directory as a target for moves and clones of content URL passed to createItemBasedOnTemplate or modifyItem. If the system cannot find a suitable directory, this calls will fail. This could happen e.g. if the domain does not exist or is in instance of initialization. This call succeeds when called from the extension process with an instance of the extension for the domain unless domain was disconnected by `-[NSFileProviderExternalVolumeHandling shouldConnectExternalDomainWithCompletionHandler:]`. It can also fail in the extension process if the domain (external) is being setup for the very first time (meaning it never existed).
      */
@@ -79,7 +81,7 @@ export declare class _NSFileProviderManager extends _NSObject {
     /**
      * Calling this method will cause the system to cancel throttling on every item which has been throttled due to the given error. This call supports the following errors: - NSFileProviderErrorNotAuthenticated - NSFileProviderErrorInsufficientQuota - NSFileProviderErrorServerUnreachable - NSFileProviderErrorCannotSynchronize - NSFileProviderErrorExcludedFromSync
      */
-    signalErrorResolved$completionHandler$(error: _NSError, completionHandler: NobjcObject | null): void;
+    signalErrorResolved$completionHandler$(error: _NSError, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Returns the global progress for the specified kind of operations This progress tracks all the ongoing kind of operations (from disk to the provider). Uploading operations are the operations from disk to the provider. Downloading operations are the operations from the provider to the disk. The global progress exposes the two following data: - Number of items with an ongoing matching kind operation along with the grand total; - Number of bytes already transferred along with the total amount of bytes to transfer. `totalUnitCount` will only be reset when there are no operations left. If new operations of the matching kind arrive while the global progress is already ongoing, they will just be summed to the existing global progress. By default, when no matching kind operations are active, the progress has its values set to 1 and its state set to finished. The progress will be updated on the main queue. It is to be retained by the caller and to be observed through KVO. The two only supported values for kind are: - NSProgressFileOperationKindUploading - NSProgressFileOperationKindDownloading The returned progress will have its fileOperationKind property set.
      */
@@ -95,29 +97,29 @@ export declare class _NSFileProviderManager extends _NSObject {
     /**
      * Notify the system that the itemIdentifiers known by the system are not valid anymore. This can be called by an extension in case it has lost track of its synchronisation state and as a consequence is not able to guarantee the stability of the itemIdentifiers anymore. In that case, the system will trigger a scan of any data that is cached on disk and call createItemBasedOnTemplate with the special NSFileProviderCreateItemMayAlreadyExist option so that the extension can specify the new itemIdentifier for those items. The provided item identifier is inclusive, meaning the specified item will be re-import as well as any children in case it is a container. In case the extension has lost its synchronisation state but is still able to guarantee the stability of the itemIdentifiers, it should make sure that querying the working set enumerator with an anchor that predates the synchronisation loss will cause a NSFileProviderErrorSyncAnchorExpired error. In case the extension has lost its synchronisation state and is not interested in preserving the data cached on disk, it can remove and re-add the affected domain. The completion handler is called as soon as the reimport is initiated and does not not reflect the end of the import. When the import of the file hierarchy is finished, the system calls -[NSFileProviderExtension importDidFinishWithCompletionHandler:]. In some circumstances, in particular in case the requested item is the root item, calling reimport will cause the system to stop the extension process. If the call is initiated from the extension, the system does not guarantee that the completion handler will be called before the extension is stopped. When called on the root item, reimport will cause the system to rebuild its backing store for the domain. See `-[NSFileProviderDomain backingStoreIdentity]`. If this method succeeds, the system will reimport at least the requested sub-tree, but may import more. If the requested item has no on-disk representation, the completion handler will be called with a NSFileProviderErrorNoSuchItem error. The same error will be reported if the reimport request happens quickly after a previous import / reimport and the corresponding item hasn't been reimported yet.
      */
-    reimportItemsBelowItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    reimportItemsBelowItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Request that the system schedules a call to -[NSFileProviderReplicatedExtension modifyItem:] for the given item identifier. The fields passed to modifyItem will contain at least the set requested via the `fields` parameter. The completion handler is called when the system has persisted the request. There is no guarantee as to when the modifyItem call will be scheduled. The completion handler may be called with an error. If the provider passes the `.content` field when the item is not downloaded, or when the item is a folder, then the system will return CocoaError(.ubiquitousFileUnavailable).
      */
-    requestModificationOfFields$forItemWithIdentifier$options$completionHandler$(fields: NSFileProviderItemFields, itemIdentifier: _NSString, options: NSFileProviderModifyItemOptions, completionHandler: NobjcObject | null): void;
+    requestModificationOfFields$forItemWithIdentifier$options$completionHandler$(fields: NSFileProviderItemFields, itemIdentifier: _NSString, options: NSFileProviderModifyItemOptions, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Request that the system remove an item from its cache. When called on a file, the file will be made dataless. When called on a directory, first each of the directory's children will be evicted (child files are made dataless, child directories are recursively evicted). Then the directory itself will be made dataless. If a non-evictable child is encountered, eviction will stop immediately and the completionHandler will be called with the NSFileProviderErrorNonEvictableChildren error. The error will include information on why and which children could not be evicted in -[NSError underlyingErrors]. The materialization state of the remaining items may be either materialized or evicted, depending on the traversal order. The completion handler is called after the items have been evicted from disk or immediately when an error occurs. Eviction might fail with the following errors : - NSFileProviderErrorDomain.NSFileProviderErrorUnsyncedEdits if the item had non-uploaded changes. - NSFileProviderErrorDomain.NSFileProviderErrorNonEvictable if the item has been marked as non-purgeable by the provider. - NSPOSIXErrorDomain.EBUSY : if the item has open file descriptors on it. - NSPOSIXErrorDomain.EMLINK : if the item has several hardlinks. - other NSPOSIXErrorDomain error codes if the system was unable to access or manipulate the corresponding file.
      */
-    evictItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    evictItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Wait for all changes on disk in the sub-hierarchy of the item to be acknowledged by the extension. This call can be used to guarantee operation ordering in a sub-hierarchy of the provider. The completion handler is called when all the changes for descendents of the item have been acknowledged by the extension. If any error is met during that process, an error will be raised, in which case the caller should not assume all the changes have been received. This call will only wait for changes affecting items that were already descendents of the requested item in the provider, or items that have been newly created on disk. It will not wait for items that are already known from the provider and are being moved in the directory. As a consequence, that call can be used from within a call to -[NSFileProviderReplicatedExtension modifyItem:baseVersion:changedFields:contents:options:completionHandler:]. Also note that the call will return immediately on items that are not directories. In case a change cannot be applied to the provider, the call will fail with NSFileProviderErrorCannotSynchronize including the NSFileProviderErrorItemKey with the identifier of the item that could not be synced if that item is known by the provider.
      */
-    waitForChangesOnItemsBelowItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    waitForChangesOnItemsBelowItemWithIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Wait for stabilization of the domain. The system will wait until it is caught up with the file system's changes up to the time of the call, then wait until it is caught up with the provider's changes up to the time of the call. The completion handler is called when both sets of changes are caught up to at least the time of the call. This is useful to enforce a consistent state for testing.
      */
-    waitForStabilizationWithCompletionHandler$(completionHandler: NobjcObject | null): void;
-    disconnectWithReason$options$completionHandler$(localizedReason: _NSString, options: NSFileProviderManagerDisconnectionOptions, completionHandler: NobjcObject | null): void;
-    reconnectWithCompletionHandler$(completionHandler: NobjcObject | null): void;
+    waitForStabilizationWithCompletionHandler$(completionHandler: ((error: _NSError) => void) | null): void;
+    disconnectWithReason$options$completionHandler$(localizedReason: _NSString, options: NSFileProviderManagerDisconnectionOptions, completionHandler: ((error: _NSError) => void) | null): void;
+    reconnectWithCompletionHandler$(completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Request that the system schedule a download for an item. The completion handler is called when the system acknowledges the download request, or with an error indicating why it didn't (e.g NSFileProviderErrorNoSuchItem.) The system will then call -fetchContentsForItemWithIdentifier at the earliest convenient time. Set rangeToMaterialize to NSMakeRange(offset, nbytes) to request a partial download. The system will then invoke -fetchPartialContentsForItemWithIdentifier instead of fetchContentsForItemWithIdentifier. For a full download, set rangeToMaterialize to NSMakeRange(NSNotFound, 0). -[NSFileProviderManager evictItemWithIdentifier:completionHandler:] must be called on a partially materialized file before requesting an extent to be downloaded from a later version of the file. This method cannot be used to download directories recursively. When invoked on a dataless directory, it will trigger an enumeration of the directory, causing a materialization of the directory one level down only. All the children of the directory will remain dataless after the enumeration.
      */
-    requestDownloadForItemWithIdentifier$requestedRange$completionHandler$(itemIdentifier: _NSString, rangeToMaterialize: NSRange, completionHandler: NobjcObject | null): void;
+    requestDownloadForItemWithIdentifier$requestedRange$completionHandler$(itemIdentifier: _NSString, rangeToMaterialize: NSRange, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * A directory suitable for storing state information for the domain. The returned URL is guaranteed to be on the same volume as the user visible URL and the temporary URL, making sure the system can atomatically clone/move files from that location to the user visible URL. The caller is responsible for managing the security scope of the returned URL. When syncing a domain on an external volume, all information about the sync state must be kept in this directory if the volume is to be shared between multiple machines. If the system cannot find a suitable directory, this call will fail. This could happen e.g. if the domain does not exist or is in instance of initialization. This call will not fail when called from the extension process with an active instance of the extension for that domain unless the domain is being setup for the very first time (meaning it never existed). Removing the domain will remove the corresponding directory along with it.
      */
@@ -125,17 +127,17 @@ export declare class _NSFileProviderManager extends _NSObject {
     /**
      * Request diagnostics collection for the item. This will prompt the user about an issue with the sync in the provider and ask their permission to collection diagnostic information and to send them to Apple for further analysis. This call is to be used wisely with care given there's global throttling on it preventing spamming the users. Furthermore it should be used in collaboration with Apple when you detect a misbehavior in the sync in your provider likely caused by a system bug and you need to work with Apple in order to resolve it. This will return whether the call was allowed or not - not if it suceed This method will only return an error if the user was not on a Seed build It is mandatory to provide an error for the item why the collection is requested. The error won't be shown to the user (a generic message will be shown instead) It will surface in the generated report though It is important to note that even if the call is allowed, it might not trigger diagnostic collection nor prompt to the user depending on the system state and other throttling parameters
      */
-    requestDiagnosticCollectionForItemWithIdentifier$errorReason$completionHandler$(itemIdentifier: _NSString, errorReason: _NSError, completionHandler: NobjcObject | null): void;
+    requestDiagnosticCollectionForItemWithIdentifier$errorReason$completionHandler$(itemIdentifier: _NSString, errorReason: _NSError, completionHandler: ((error: _NSError) => void) | null): void;
     /**
      * Request the specified known folders to be synced by this domain. This method allows the provider to claim a set of known folders described by the non-null properties of the knownFolders parameter. The system will only enable sync for those folders in that domain if the set of locations is valid and if the user agrees. This API should only be called as a result of the user requesting, via UI in the provider's application, that they wish to start syncing the Desktop and Document folders. If the provider chooses to implement a UI which invokes this API, the provider should also implement a UI for the user to request to stop syncing the Desktop and Document folders, using the `-[NSFileProviderManager releaseKnownFolders:localizedReason:completionHandler:]` method. The reason specified in this call is a custom string that the provider can pass and will be presented to the user as a way to explain why it is claiming those known folders. One suggested phrasing would be: > Keep your Desktop & Documents in sync with <Provider name> and access them from other devices and from <Provider website>. If the user denies the transition of the known folders, the call will fail with `NSUserCancelledError`. The call will fail if: - one or more locations are not folders - multiple locations are backed by the same folder - a known folder doesn't live on the same volume as the root of the domain - the known folders don't have the same parent folder - ... Currently, only claiming both ~/Desktop and ~/Documents together is allowed.
      */
-    claimKnownFolders$localizedReason$completionHandler$(knownFolders: _NSFileProviderKnownFolderLocations, localizedReason: _NSString, completionHandler: NobjcObject | null): void;
+    claimKnownFolders$localizedReason$completionHandler$(knownFolders: _NSFileProviderKnownFolderLocations, localizedReason: _NSString, completionHandler: ((arg0: _NSError) => void) | null): void;
     /**
      * Request that the system stops replicating the specified known folders in the domain. This call can be used by the provider to immediately disable replication of the specified known folders.
      */
-    releaseKnownFolders$localizedReason$completionHandler$(knownFolders: NSFileProviderKnownFolders, localizedReason: _NSString, completionHandler: NobjcObject | null): void;
+    releaseKnownFolders$localizedReason$completionHandler$(knownFolders: NSFileProviderKnownFolders, localizedReason: _NSString, completionHandler: ((arg0: _NSError) => void) | null): void;
     /** Retrieve the service with the specified named for the specified item. */
-    getServiceWithName$itemIdentifier$completionHandler$(serviceName: NSFileProviderServiceName, itemIdentifier: _NSString, completionHandler: NobjcObject | null): void;
+    getServiceWithName$itemIdentifier$completionHandler$(serviceName: NSFileProviderServiceName, itemIdentifier: _NSString, completionHandler: ((_Nullable_result: _NSFileProviderService, arg1: _NSError) => void) | null): void;
     /**
      * List the available operations. This lists all of the operations that are ready to be scheduled by the system. The system waits for all the pending disk and working set updates to be known before returning. The operations that are returned may become invalid if the system receives new disk or working set events, or if some operation are scheduled using -runTestingOperations:error:.
      */

package/dist/FileProvider/NSFileProviderPartialContentFetching.d.ts

@@ -1,13 +1,16 @@
-import type { NobjcObject } from "objc-js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
 import type { _NSString } from "../Foundation/NSString.js";
+import type { _NSURL } from "../Foundation/NSURL.js";
+import type { _NSFileProviderItem } from "./NSFileProviderItem.js";
 import type { _NSFileProviderItemVersion } from "./NSFileProviderItemVersion.js";
 import type { _NSFileProviderRequest } from "./NSFileProviderRequest.js";
 import type { NSRange } from "../structs/NSRange.js";
 import type { NSFileProviderFetchContentsOptions } from "./NSFileProviderFetchContentsOptions.js";
+import type { NSFileProviderMaterializationFlags } from "./NSFileProviderMaterializationFlags.js";
 export interface _NSFileProviderPartialContentFetching {
     /**
      * Download the requested extent of an item for the given identifier and return it via the completion handler. If this protocol is not implemented the system defaults to fetchContentsForItemWithIdentifier. The requestedVersion parameter specifies which version should be returned. This version will always be specified by the system so as to prevent extents from different versions from being written into the same file. The system tolerates a version mismatch for the first materialization of a fully dataless file (strictVersion=NO). The requested range is <location , length>. The implementation can provide any properly aligned range that covers the requested range (including the entire item). The system provides the minimal alignment value. The location (or start offset) of the fetched range should be a multiple of this value for it to be considered properly aligned. The length of the fetched range should be a multiple of this value, with an exception for the end of the file, checked against the documentSize attribute the implementation supplied for this item. The alignment value should not be expected to be stable across reboots. It is guaranteed by the system to be a power of two. In addition to the content the extension needs to fill in fetchedRange with either the requestest range, <location , length>, or indicate full materialization with, < 0, file size>. On-disk layout: --------------- The retrieved content at `fileContents` URL must be a regular file on the same volume as the user-visible URL. A suitable location can be retrieved using -[NSFileProviderManager temporaryDirectoryURLWithError:]. The file contents outside of the fetched range are ignored by the system. The system only requires the file to be at least as large as the end of the fetched range. For instance, if the fetchedRange is {offset:0x100000, length:0x1000}, the file size must be at least 0x101000 bytes. Any data (or lack thereof) beyond the fetched range is ignored. The fetched range must be stored in this file at the same offset as the range indicates. For instance if the retrievedRange is {offset:0x100000, length:0x1000} then it should actually be at offset 0x100000 in the `fileContents` file. The ranges {0, 0x100000}, and {0x101000, EOF} can be anything including sparse ranges. Concurrent Downloads: --------------- The system will call fetchContents concurrently if there are multiple outstanding file download requests. The provider can control the concurrency by setting the key NSExtensionFileProviderDownloadPipelineDepth in the Info.plist of the extension to the number of concurrent downloads that the system should create per domain. This number must be between 1 and 128, inclusive. File ownership: --------------- The system clones and unlinks the received fileContents. The extension should not mutate the corresponding file after calling the completion handler. If the extension wishes to keep a copy of the content, it must provide a clone of the that content as the URL passed to the completion handler. In case the extension or the system crashes between the moment the completion handler is called and the moment the system unlinks the file, the file may unexpectedly still be on disk the next time an instance of the extension is created. The extension is then responsible for deleting that file. Disallowing processes from fetching items: --------------- The system automatically downloads files on POSIX accesses. The extension may wish to disallow this class of downloads for specific applications. The extension can set an array of strings into the UserDefault key "NSFileProviderExtensionNonMaterializingProcessNames". A process whose executable's filename on disk is an exact match for an entry in this array will not be allowed to fetch items in the extension's domains. The comparison is case sensitive. In macOS 11.0 and later, this list will be checked when a download is initiated through a POSIX filesystem call. In macOS 11.4 and later, this list will also be checked for downloads initiated through file coordination. Error cases: ------------ If the download fails because the item is unknown, the call should fail with the NSFileProviderErrorNoSuchItem error. In that case, the system will consider the item has been removed from the domain and will attempt to delete it from disk. In case that deletion fails because there are local changes on this item, the system will re-create the item using createItemBasedOnTemplate. If the user does not have access to the content of the file, the provider can fail the call with NSCocoaErrorDomain and code NSFileReadNoPermissionError. That error will then be presented to the user. The extension can also report the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable in case the item cannot be fetched because of the current state of the system / domain. In those cases, the system will present an appropriate error message and back off until the next time it is signalled. If the requested version cannot be retrieved, the provider can choose to provide a different version of the file, unless NSFileProviderFetchContentsOptionsStrictVersioning is set. In this case, the provider should fail with NSFileProviderErrorVersionNoLongerAvailable. If some content is returned, the item must have the corresponding version. The system will detect any mismatch and handle it as a remote update. For the reading application, the materialization will fail with the same error as reading from a dataless file that got remotely updated (-1/errno=ESTALE). Upon retry the new version will be requested by the system. Any other error will be considered to be transient and will cause the download to be retried. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, nil, someRange, 0, NSUserCancelledError) in the NSProgress cancellation handler. The returned NSProgress is used to show progress to the user. If the user cancels the fetch, the extension should stop fetching the item, as it is no longer required. Execution time: --------------- The system will grant enough time to the extension to download the file. The system will interrupt the call if it stops making progress or if download takes an unexpectedly long time. In that case, the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    fetchPartialContentsForItemWithIdentifier$version$request$minimalRange$aligningTo$options$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion, request: _NSFileProviderRequest, requestedRange: NSRange, alignment: number, options: NSFileProviderFetchContentsOptions, completionHandler: NobjcObject | null): _NSProgress;
+    fetchPartialContentsForItemWithIdentifier$version$request$minimalRange$aligningTo$options$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion, request: _NSFileProviderRequest, requestedRange: NSRange, alignment: number, options: NSFileProviderFetchContentsOptions, completionHandler: ((fileContents: _NSURL, item: _NSFileProviderItem, retrievedRange: NSRange, flags: NSFileProviderMaterializationFlags, error: _NSError) => void) | null): _NSProgress;
 }

package/dist/FileProvider/NSFileProviderReplicatedExtension.d.ts

@@ -1,9 +1,9 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSFileProviderDomain } from "./NSFileProviderDomain.js";
 import type { _NSFileProviderEnumerating } from "./NSFileProviderEnumerating.js";
 import type { _NSFileProviderItem } from "./NSFileProviderItem.js";
 import type { _NSFileProviderItemVersion } from "./NSFileProviderItemVersion.js";
 import type { _NSFileProviderRequest } from "./NSFileProviderRequest.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
 import type { _NSString } from "../Foundation/NSString.js";
 import type { _NSURL } from "../Foundation/NSURL.js";
@@ -21,33 +21,33 @@ export interface _NSFileProviderReplicatedExtension extends _NSFileProviderEnume
     /**
      * Fetch the metadata for the item with the provider identifier. Error cases: ------------ If the metadata lookup fails because the item is unknown, the call should fail with the NSFileProviderErrorNoSuchItem error. In that case, the system will consider the item has been removed from the domain and will attempt to delete it from disk. In case that deletion fails because there are local changes on this item, the system will re-create the item using createItemBasedOnTemplate. The extension can also report the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable in case the item cannot be fetched because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. Any other error, including crashes of the extension process, will be considered to be transient and will cause the lookup to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This method is not expected to take more than a few seconds to complete the retrieval of the metadata of the item. If the operation may not complete in a reasonable amount of time because, for instance, of bad network conditions, it is recommended to report an error (for instance NSFileProviderErrorServerUnreachable). The system will call `cancel` on the progress if the operation takes too much time. The extension is then expected to quickly call the completion handler.
      */
-    itemForIdentifier$request$completionHandler$?(identifier: _NSString, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    itemForIdentifier$request$completionHandler$?(identifier: _NSString, request: _NSFileProviderRequest, completionHandler: ((arg0: _NSFileProviderItem, arg1: _NSError) => void) | null): _NSProgress;
     /**
      * Download the item for the given identifier and return it via the completion handler. The system learns of items through enumerations. Initially, this means that the system is aware that an item (with a specific version) exists on the device. When the user accesses the item, the system makes a request for the contents of the item. The provider can then fulfill the request by providing the item. The system takes ownership of the item and will move it out of the sandbox of the provider. If the provider wishes to force materialization of a given item, the provider should use `-[NSFileProviderManager requestDownloadForItemWithIdentifier:requestedRange:completionHandler:]`, or configure the `-[NSFileProviderItem contentPolicy]`. The requestedVersion parameter specifies which version should be returned. A nil value means that the latest known version should be returned. Except for the error case, the version of the returned item is assumed to be identical to what was requested. requestedVersion is currently always set to nil. Concurrent Downloads: ---------- The system will call fetchContents concurrently if there are multiple outstanding file download requests. The provider can control the concurrency by setting the key NSExtensionFileProviderDownloadPipelineDepth in the Info.plist of the extension to the number of concurrent downloads that the system should create per domain. This number must be between 1 and 128, inclusive. File ownership: --------------- The retrieved content at `fileContents` URL must be a regular file on the same volume as the user-visible URL. A suitable location can be retrieved using -[NSFileProviderManager temporaryDirectoryURLWithError:]. The system clones and unlinks the received fileContents. The extension should not mutate the corresponding file after calling the completion handler. If the extension wishes to keep a copy of the content, it must provide a clone of the that content as the URL passed to the completion handler. In case the extension or the system crashes between the moment the completion handler is called and the moment the system unlinks the file, the file may unexpectedly still be on disk the next time an instance of the extension is created. The extension is then responsible for deleting that file. Disallowing processes from fetching items: --------------- The system automatically downloads files on POSIX accesses. The extension may wish to disallow this class of downloads for specific applications. The extension can set an array of strings into the UserDefault key "NSFileProviderExtensionNonMaterializingProcessNames". A process whose executable's filename on disk is an exact match for an entry in this array will not be allowed to fetch items in the extension's domains. The comparison is case sensitive. In macOS 11.0 and later, this list will be checked when a download is initiated through a POSIX filesystem call. In macOS 11.4 and later, this list will also be checked for downloads initiated through file coordination. Error cases: ------------ If the download fails because the item was deleted on the server, the call should fail with the NSFileProviderErrorNoSuchItem error. In that case, the system will consider the item has been removed from the domain and will attempt to delete it from disk. In case that deletion fails because there are local changes on this item, the system will re-create the item using createItemBasedOnTemplate, passing the NSFileProviderCreateItemDeletionConflicted flag. If the user does not have access to the content of the file, the provider can fail the call with NSCocoaErrorDomain and code NSFileReadNoPermissionError. That error will then be presented to the user. The extension can also report the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable in case the item cannot be fetched because of the current state of the system / domain. In those cases, the system will present an appropriate error message and back off until the next time it is signalled. Any other error, including crashes of the extension process, will be considered to be transient and will cause the download to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, nil, NSUserCancelledError) in the NSProgress cancellation handler. The returned NSProgress is used to show progress to the user. If the user cancels the fetch, the extension should stop fetching the item, as it is no longer required. Execution time: --------------- The system will grant enough time to the extension to download the file. The system will interrupt the call if it stops making progress or if download takes an unexpectedly long time. In that case, the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    fetchContentsForItemWithIdentifier$version$request$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion | null, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    fetchContentsForItemWithIdentifier$version$request$completionHandler$?(itemIdentifier: _NSString, requestedVersion: _NSFileProviderItemVersion | null, request: _NSFileProviderRequest, completionHandler: ((fileContents: _NSURL, item: _NSFileProviderItem, error: _NSError) => void) | null): _NSProgress;
     /**
      * Create a new item. The itemTemplate object describes the expected state of the newly created item, including its location provided by parentItemIdentifier and filename. The list of fields to conside in that object is defined by the fields parameter. Fields not listed should be considered as not being defined. The url is used to transfer the content of the file from the system to the extension. It can be nil if the item has no content. This will be the case if the item is a folder or if the item is being reimported (flag NSFileProviderCreateItemMayAlreadyExist set) and the file is dataless on disk. If the item is a symbolic link, the target path is provided by the symlinkTargetPath of the itemTemplate. The system is setting the itemIdentifier of the itemTemplate to a unique value that is guaranteed to stay the same for a given item in case the creation is replayed after a crash. That itemIdentifier is not intended to be the identifier assigned to the item by the provider. In the completion block, the createdItem is expected to reflect the properties of the newly created item, which usually means matching the properties passed in by the template. An exception is the itemIdentifier which should be the identifier assigned to that item by the provider rather than the identifier passed in through the template. If the provider reuses an existing identifier, the item that used that identifier will be removed from disk, replaced by the createdItem. If the item is a directory, the two directories will be merged and the items from the existing one will be modified with the NSFileProviderModifyItemMayAlreadyExist option set. If the provider is not able to apply all the fields at once, it should return a set of stillPendingFields in its completion handler. In that case, the system will attempt to modify the item later by calling modifyItem with those fields. The filename and contents fields should be synced together. If synced independently, files may appear corrupted on other devices, due to a mismatch between the file extension and the actual file data. If a field in the returned createdItem does not match the itemTemplate, and is not in the list of stillPendingFields, the value from the createdItem will be propagated to the disk. If the content of the item as described by createdItem does not match the content from url, the provider should set shouldFetchContent in the completion handler. The content from the provider will then be fetched and propagated to disk. In case the deletion of an item from the working set could not be applied to the disk by the system because it conflicted with a local edit of the file, the system will attempt to create the edited item. In that case the creation call will receive the NSFileProviderCreateItemDeletionConflicted option and the itemIdentifier in the template will be set to the itemIdentifier of the item deleted from the working set. The itemVersion will also be set to the last itemVersion of the item that was made available on disk before the item was edited locally. If such a conflict happens on a dataless item on disk, the item will be immediately deleted from the disk instead of issuing a new creation. In case the NSFileProviderCreateItemMayAlreadyExist option is passed, the content may be nil if the item is found by the system without any associated content. In that case, you should return a nil item if you are not able to match the created item with an existing item from the provider. In case of path collision with an already existing item, the provider can either fail using -[NSError (NSFileProviderError) fileProviderErrorForCollisionWithItem:] or resolve the collision by itself (e.g. by returning an item with a different name). If the error is returned, the system will try to resolve the collision by itself by bouncing away one of the items (renaming the item). If the imported item is refused by the extension, it should return nil for the createdItem without any error. In that case, the source item will be deleted from disk. In case the item represents a directory, the content will be deleted recursively. If the extension does not wish to sync the item, while still keeping the item on disk, on macOS 13.0, iOS 16.0, and later, it should return `NSFileProviderErrorExcludedFromSync` on the completion handler. For more details, see the header comment for that error code. On earlier versions of macOS, where `NSFileProviderErrorExcludedFromSync` is unavailable, the extension could choose to respond to FileProvider API calls as if the item is synced to it's server, but the extension only tracks the item in it's own local database on the device. The extension must be careful to respond to all FileProvider API calls as if the file is really synced to it's server, including enumerations of the parent directory of that item, itemForIdentifier calls, etc. The progress returned by createItemBasedOnTemplate is expected to include the upload progress of the item and will be presented in the user interface until the completion handler is called. Creation is gated by the NSFileProviderItemCapabilitiesAllowsAddingSubItems capability on the parent folder on a UI level, but direct file system changes (e.g. from Terminal) can still result in changes that must be handled. Structural consistency: ----------------------- The system guarantees that the creation is called after the creation of the parent completed. File ownership: --------------- The file at `url` is owned by the system and is unlinked after the completion handler is called. If the extension wishes to keep access to the content of file after calling the completion handler, it should clone the file in its container. Atomicity: ---------- By default, the system assumes all the changes are applied non-atomically, which means that the change or an intermediary state from the change can be observed (for instance while enumerating the working set) while the call is in progress (before the completion handler is called). The provider can indicate to the system that it applies changes atomically (that is, the change cannot be observed before the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically in the Info.plist of the extension to YES. The atomicity declaration only describes the visibility of the changes, not the ability of the provider to apply all the fields at once: a provider that applies changes atomically might still apply a subset of the changedFields communicated by the system and defer the remaining fields by setting the stillPendingFields parameter in the completion handler. Error cases: ------------ If the creation fails because the target directory does not exist, the extension must fail the creation using the NSFileProviderErrorNoSuchItem error code. In that case, the system will attempt the re-create the parent directory. In case the location of the new item is already in use by another item, the extension can chose to either resolve the collision by moving one of the items away, or reject the creation with the NSFileProviderErrorFilenameCollision error code. In that error case, the system will be responsible for resolving the collision, by renaming one of the colliding items. When the collision is resolved, the system will call createItemBasedOnTemplate again. The extension can also report NSFileProviderErrorNotAuthenticated, NSFileProviderErrorCannotSynchronize, or NSFileProviderErrorExcludedFromSync, in case the modification cannot be applied because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. The provider can signal the error resolution by calling signalErrorResolved:completionHandler:. Any other error, including crashes of the extension process, will be considered to be transient and will cause the creation to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, [], NO, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- The system will grant enough time to the extension to upload the file if content is passed to the call, otherwise the call is expected to completed within a few seconds. The system will interrupt the call if it stops making progress or if upload takes an unexpectedly long time. In that case, the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    createItemBasedOnTemplate$fields$contents$options$request$completionHandler$?(itemTemplate: _NSFileProviderItem, fields: NSFileProviderItemFields, url: _NSURL | null, options: NSFileProviderCreateItemOptions, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    createItemBasedOnTemplate$fields$contents$options$request$completionHandler$?(itemTemplate: _NSFileProviderItem, fields: NSFileProviderItemFields, url: _NSURL | null, options: NSFileProviderCreateItemOptions, request: _NSFileProviderRequest, completionHandler: ((createdItem: _NSFileProviderItem, stillPendingFields: NSFileProviderItemFields, shouldFetchContent: boolean, error: _NSError) => void) | null): _NSProgress;
     /**
      * Informs the provider that an item or its metadata have changed. More than one property may have changed, e.g. an item may have been renamed, moved and also changed contents, in which case changedFields might contain [.contents, .filename, .parentItemIdentifier, .contentModificationDate]. If the provider is not able to apply all the fields at once, it should return a set of stillPendingFields in its completion handler. In that case, the system will attempt to modify the item later by calling modifyItem with those fields. The filename and contents fields should be synced together. If synced independently, files may appear corrupted on other devices, due to a mismatch between the file extension and the actual file data. Starting in macOS 12.0, if the set of stillPendingFields returned by the provider is identical to the set of fields passed to modifyItem, then the system will consider that these fields are not supported by the provider. The system will not send these fields to the provider again, until the item is modified. If a field in the returned item does not match the itemTemplate, and is not in the list of stillPendingFields, the value from the item will be propagated to the disk. In case there is a content change and the content of the returned item as described by item does not match the content from url, the provider should set shouldFetchContent in the completion handler. The content from the provider will then be fetched and propagated to disk. If the item modification results from the parent directory being merged into another directory, the NSFileProviderModifyItemMayAlreadyExist flag will be passed to the call. The provider can chose to merge two existing items when receiving modifyItem. In that case, the item returned should carry the itemIdentifier of the item with which the item will be merged and well as the resulting state of that item. The system will then keep one of the items (the one whose itemIdentifier was returned) and remove the other one from disk. In case of directories, the content of the two directories is merged and sub-items will be modified with the NSFileProviderModifyItemMayAlreadyExist flag set. If the extension wishes the modify item to cause the deletion of the item on disk, it can call the completion handler with nil in place of the resulting item. If the item is directory, the item will be kept on disk until all its children has been deleted from the working set. The system will only apply the deletion on the disk if this does not conflict with local edits. Otherwise, the system will attempt to re-create the item with the NSFileProviderCreateItemDeletionConflicted option set. The progress returned by modifyItem is expected to include the upload progress if any, even if the provider chose to call the completion handler before the upload finishes. For example, the provider might decide to call the completion handler as soon as the metadata have been stored in a local database. Modifications are gated by the corresponding capabilities of the item on a UI level, but direct file system changes (e.g. from Terminal) can still result in changes that must be handled. Conflict resolution: ------------------- The system passes a `baseVersion` parameter to the modifyItem call. This baseVersion describes the latest version of the file which was reflected on disk. This parameter can be used to detect conflicts with remote edits. For instance, if content version A of the file was downloaded to the local system, and the content was modified locally, the modifyItem call will receive baseVersion of A. If the server has in the meantime received another content edit of the same file, the server may have content version C. In this case, the extension can detect the mismatching baseVersion, and decide how to resolve the conflict. The extension informs the system of how it wishes to resolve the conflict by returning the resolved metadata on the completion handler. As an example resolution, if the extension informs that it wishes for the remote version of the item to be on disk (and to ignore the local edits), it should return the new contentVersion in the completion handler's item. The system will subsequently call fetchContents to retrieve the new contents and replace them on disk. The `baseVersion` might contain one or both component set to `+[NSFileProviderItemVersion beforeFirstSyncComponent]`, in case there has never been a version for which the item on disk and the item in the provider were known to be in sync. Structural consistency and Cycle handling: ------------------------------------------ In case the parentItemIdentifier is modified, the system guarantees that the new parent has been created and the creation completed before the call to modifyItem is issued. The system guarantees that modifyItem called after local changes from the user will never create a cycle: that is all items will always be a descendent of either the root item or the trash item. However, cycles that are caused by concurrent local changes by the user and changes on the remote server can also create cycles. This is handled by the system as a conflict. This means the provider must validate that the call of modifyItem is not creating a cycle with a change it observed from the server. If such a cycle is detected, the provider must fix the conflict by breaking the cycle, and return the state of the item after resolving that conflict. If the resolution affects other items as well, updates for those other items must be published on the working set. File ownership: --------------- The file at `url` is owned by the system and is unlinked after the completion handler is called. If the extension wishes to keep access to the content of file after calling the completion handler, it should clone the file in its container. Atomicity: ---------- By default, the system assumes all the changes are applied non-atomically, which means that the change or an intermediary state from the change can be observed (for instance while enumerating the working set) while the call is in progress (before the completion handler is called). The provider can indicate to the system that it applies changes atomically (that is, the change cannot be observed before the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically in the Info.plist of the extension to YES. The atomicity declaration only describes the visibility of the changes, not the ability of the provider to apply all the fields at once: a provider that applies changes atomically might still apply a subset of the changedFields communicated by the system and defer the remaining fields by setting the stillPendingFields parameter in the completion handler. Error cases: ------------ The extension may fail the modification if the modified item does not exist anymore. In that case, the extension should fail the call the NSFileProviderErrorNoSuchItem error code. The system will attempt to delete the item on disk. If the item on disk actually has changes since this call to modifyItem, then it will be re-created by a call to createItemBasedOnTemplate. Likewise, if the item is reparented to a parent that no longer exists, the extension may return a NSFileProviderErrorNoSuchItem error with the parent item. In case the modification updates the location of the item and another item is already known at this location, the extension can chose to either resolve the collision by moving one of the items away, or reject the modification with the NSFileProviderErrorFilenameCollision error code. In that error case, the system will be responsible for resolving the collision, by renaming one of the colliding items. When the collision is resolved, the system will call modifyItem again. In case the NSFileProviderModifyItemFailOnConflict option is passed, the provider should fail the modification if the baseVersion does not match the version on the server. It will be up to the system to merge the conflict and call modifyItem again with an updated baseVersion. The extension can also report NSFileProviderErrorNotAuthenticated, NSFileProviderErrorCannotSynchronize, or NSFileProviderErrorExcludedFromSync, in case the modification cannot be applied because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. The provider can signal the error resolution by calling signalErrorResolved:completionHandler:. Any other error, including crashes of the extension process, will be considered to be transient and will cause the modification to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, [], NO, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- The system will grant enough time to the extension to upload the file if content is passed to the call, otherwise the call is expected to completed within a few seconds. The system will interrupt the call if it stops making progress or if upload takes an unexpectedly long time. In that case, the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    modifyItem$baseVersion$changedFields$contents$options$request$completionHandler$?(item: _NSFileProviderItem, version: _NSFileProviderItemVersion, changedFields: NSFileProviderItemFields, newContents: _NSURL | null, options: NSFileProviderModifyItemOptions, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    modifyItem$baseVersion$changedFields$contents$options$request$completionHandler$?(item: _NSFileProviderItem, version: _NSFileProviderItemVersion, changedFields: NSFileProviderItemFields, newContents: _NSURL | null, options: NSFileProviderModifyItemOptions, request: _NSFileProviderRequest, completionHandler: ((item: _NSFileProviderItem, stillPendingFields: NSFileProviderItemFields, shouldFetchContent: boolean, error: _NSError) => void) | null): _NSProgress;
     /**
      * Delete an item forever. This is called when the user deletes an item that was already in the Trash and the item should no longer appear there after this call. This call should remove the item from the working set. This call receives an optional baseVersion which represent the version of the item we are trying to delete. Unless the NSFileProviderDeleteItemRecursive options is passed, the deletion of a directory should be non-recursive. If the deletion is recursive the provider should take care of reporting the deletion of all the deleted items through the working set. Delete is gated by the capabilities of the removed item with NSFileProviderItemCapabilitiesAllowsDeleting. Modifications are gated by NSFileProviderItemCapabilitiesAllowsDeleting of the item on a UI level, but direct file system changes (e.g. from Terminal) can still result in changes that must be handled. Atomicity: ---------- By default, the system assumes all the changes are applied non-atomically, which means that the change or an intermediary state from the change can be observed (for instance while enumerating the working set) while the call is in progress (before the completion handler is called). The provider can indicate to the system that it applies changes atomically (that is, the change cannot be observed before the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically in the Info.plist of the extension to YES. Error cases: ------------ The extension may fail the deletion in different scenarios, for instance because the baseVersion is out of date or because the user does not have permissions to delete the item. In that case the extension should fail the call with the NSFileProviderErrorDeletionRejected error code which will cause the system to re-create the deleted item on disk based on the latest metadata available from the extension. If the options don't include NSFileProviderDeleteItemRecursive and the deletion targets a non-empty directory, the extension must reject the deletion with the NSFileProviderErrorDirectoryNotEmpty error code. This error can also be reported in case some children of the directory cannot be deleted when receiving the NSFileProviderDeleteItemRecursive option. In both cases, the system will re-create the deleted item on disk based on the latest metadata available from the extension. If the deletion targets an item that is unknown from the extension because that item may have already been deleted remotely, then the extension should report a success. The extension can also report the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable, or NSFileProviderErrorCannotSynchronize in case the deletion cannot be applied because of the current state of the system / domain. In that case, the system will present an appropriate error message and back off until the next time it is signalled. Any other error, including crashes of the extension process, will be considered to be transient and will cause the deletion to be retried. Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain. For errors which can not be represented using an existing error code in one of these domains, the extension should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid. The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not be represented. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This call is not expected to take more than a few seconds to complete. The system will interrupt the call if it stops making progress or if the deletion takes an unexpectedly long time. In that case,the system will call `cancel` on the progress. The extension is then expected to quickly call the completion handler.
      */
-    deleteItemWithIdentifier$baseVersion$options$request$completionHandler$?(identifier: _NSString, version: _NSFileProviderItemVersion, options: NSFileProviderDeleteItemOptions, request: _NSFileProviderRequest, completionHandler: NobjcObject | null): _NSProgress;
+    deleteItemWithIdentifier$baseVersion$options$request$completionHandler$?(identifier: _NSString, version: _NSFileProviderItemVersion, options: NSFileProviderDeleteItemOptions, request: _NSFileProviderRequest, completionHandler: ((arg0: _NSError) => void) | null): _NSProgress;
     /**
      * Signal the end of import of on-disk items. This is called after a reimport of on-disk items has been triggered by either `-[NSFileProviderManager reimportItemsBelowItemWithIdentifier:completionHandler:]` or after a new domain is created using `+[NSFileProviderManager importDomain:fromDirectoryAtURL:completionHandler:]` or `+[NSFileProviderManager addDomain:completionHandler:]`. `reimport` can also be started by the system independently from any request by the provider. The provider can detect those events by monitoring `-[NSFileProviderDomain backingStoreIdentity]`. During import, found items will be created via the -[NSFileProviderExtension createItemBasedOnTemplate:fields:contents:options:completionHandler:] call with the NSFileProviderCreateItemMayAlreadyExist flag set. At the end of an import the -[NSFileProviderExtension importDidFinishWithCompletionHandler:] is called. The system will attempt to import items as they are accessed by the user or applications. Import of the other items is scheduled by the system as a background task. That task may be delayed, for instance in low-power situations, or when the system is under heavy load. The provider can force the system to process a folder and its direct children by issuing a coordination request on that folder. Execution time: --------------- This call is not expected to take more than a few seconds to complete.
      */
-    importDidFinishWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    importDidFinishWithCompletionHandler$?(completionHandler: () => void): void;
     /**
      * Called by the system if the set of materialized items changes. Materialized items are items that have synced to disk and are not dataless. They may contain a mix of dataless and materialized files and directories, but in any case, all their children are represented on disk. Traversals of dataless directories by applications trigger an enumeration against the file provider extension; traversals of materialized directories do not. It is the responsability of the file provider extension to notify the system on remote changes of these files: there is no alternative cache invalidation mechanism. If the extension doesn't keep track of the materialized set, it will have to notify the system of all remote changes. In that case the working set is the entire dataset. The system may drop items whose parent isn't materialized, to avoid unnecessary disk usage. This saves some I/O, but isn't optimal. The filtering by parentItemIdentifier is better done in the extension; ideally, it would even be done server-side. A hybrid model is possible, where some filtering is done server-side, and some finer filtering is done client-side. The file provider extension should therefore keep a list of the identifiers of the materialized directories. This method is called when a new directory is materialized or when a materialized directory is rendered dataless. To enumerate the set of materialized containers, - Call -enumeratorForMaterializedItems on the instance of NSFileProviderManager corresponding to your domain; - Implement the NSFileProviderEnumerationObserver and NSFileProviderChangeObserver on an object; - Pass that object to the enumerator; - Use the identifiers of items or changes you receive to note the materialization status in your database. When an item is created, modified or deleted remotely, the file provider extension should check whether its parentItemIdentifier is in the materialized set. If it is, the extension needs to inform the system so the system may create, modify or delete the file or directory (initially dataless) on disk. In the case when an item is reparented, the test should be that either the new or the old parentItemIdentifier is in the materialized set. No need to pretend that the iten was deleted if the new parentItemIdentifier is no longer in the materialized set: the system will know what to do with an unknown parent identifier. To notify the system of this created, modified or deleted item, - Call -signalEnumeratorForContainerItemIdentifier: on the working set, i.e the container identified by NSFileProviderWorkingSetContainerItemIdentifier; - Include this item in the next enumeration of the working set. Since this method is called on every change of the set of materialized items, it is advisable to use it to set a flag and perform any resulting work as a timed task rather than performing any work directly. Execution time: --------------- This call is not expected to take more than a few seconds to complete.
      */
-    materializedItemsDidChangeWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    materializedItemsDidChangeWithCompletionHandler$?(completionHandler: () => void): void;
     /**
      * Called by the system when the set of pending items is refreshed. The pending enumerator lists all the items for which a change has been observed either on the disk or in the working set more than one second ago and that change hasn't been applied on the other side yet. An item can appear in the pending set for various reasons: - the system is under load and cannot process all the events in a timely fashion - a long running operation is scheduled or running for the item to be in sync (for instance, the download or the upload of a new content) - an error occurred, in which case the error will be set on the item as `downloadError` if it occurred when applying a change to the disk, or `uploadError` in the other way around. The pending set will only include items that comply to the following rules: - They have been queued for changes for more time than the refresh interval; - The items are already known by the provider. These constraints imply that initial transfer of a file from the disk to the provider will not be listed in the pending set, even though the transfer could take several minutes to complete Furthermore, the pending set can only contain a limited number of items. The pending set provides an easy way to design an "in progress" UI containing a few items and to detect whether there's any activity pending on the system. In case the pending set reached its maximum size items, newly pending items won't be included in it. Already present items in the pending set will remain until they no longer are pending. The pending set is refreshed regurlary but only if there are meaningful changes: new pending items, items that were pending but are not anymore (deletions from the set), or domain version changed and set is not empty To enumerate the set of pending items, - Call -enumeratorForPendingItems on the instance of NSFileProviderManager corresponding to your domain; - Implement the NSFileProviderEnumerationObserver and NSFileProviderChangeObserver on an object; - Pass that object to the enumerator; - It will get called upon change to the set. This method is regularly called when changes happen to the pending set. implementeers are advised that this call will not happen as soon as an item is pending. Thus, implementeers should not use the pending set to detect when a change happens. The pending set will only contain items that were pending for a least one second before the last refresh date. Execution time: --------------- This call is not expected to take more than a few seconds to complete.
      */
-    pendingItemsDidChangeWithCompletionHandler$?(completionHandler: NobjcObject): void;
+    pendingItemsDidChangeWithCompletionHandler$?(completionHandler: () => void): void;
 }

package/dist/FileProvider/NSFileProviderServicing.d.ts

@@ -1,9 +1,10 @@
-import type { NobjcObject } from "objc-js";
+import type { _NSArray } from "../Foundation/NSArray.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
 import type { _NSString } from "../Foundation/NSString.js";
 export interface _NSFileProviderServicing {
     /**
      * A file provider can implemement this method to return service sources that provide custom communication channels to client applications. The service sources must be tied to the item identified by Client applications can retrieve the list of supported services by calling getFileProviderServicesForItemAtURL:] for a specific item URL. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (nil, NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This method is not expected to take more than a few seconds to complete the retrieval of the thumbnails. The system will call `cancel` on the progress if the operation takes too much time. The extension is then expected to quickly call the completion handler.
      */
-    supportedServiceSourcesForItemIdentifier$completionHandler$?(itemIdentifier: _NSString, completionHandler: NobjcObject | null): _NSProgress;
+    supportedServiceSourcesForItemIdentifier$completionHandler$?(itemIdentifier: _NSString, completionHandler: ((arg0: _NSArray, arg1: _NSError) => void) | null): _NSProgress;
 }

package/dist/FileProvider/NSFileProviderThumbnailing.d.ts

@@ -1,10 +1,12 @@
-import type { NobjcObject } from "objc-js";
 import type { _NSArray } from "../Foundation/NSArray.js";
+import type { _NSData } from "../Foundation/NSData.js";
+import type { _NSError } from "../Foundation/NSError.js";
 import type { _NSProgress } from "../Foundation/NSProgress.js";
+import type { _NSString } from "../Foundation/NSString.js";
 import type { CGSize } from "../structs/CGSize.js";
 export interface _NSFileProviderThumbnailing {
     /**
      * The system calls this method to fetch thumbnails. The should be called for each thumbnail, and only after all the per thumbnail completion blocks. In the event of a global error, the implementation is allowed to skip calling the for individual thumbnails. In that case, the error parameter would apply to all item identifiers for which had not been called. If there is no thumbnail for a given item, the should be called with its and parameters both set to nil. If the system decides that an in-flight thumbnail request is not needed anymore, it will call the returned object's method, at which time the implementation should clean up any held resources. The system will cache the thumbnail for the item, and the cache will be invalidated when itemVersion.contentVersion changes. Thread safety: ------------ The may be called from multiple threads concurrently. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (NSUserCancelledError) in the NSProgress cancellation handler. Execution time: --------------- This method is not expected to take more than a few tens seconds to complete the retrieval of the services exposed on the item. The system will call `cancel` on the progress if the operation takes too much time. The extension is then expected to quickly call the completion handler.
      */
-    fetchThumbnailsForItemIdentifiers$requestedSize$perThumbnailCompletionHandler$completionHandler$?(itemIdentifiers: _NSArray, size: CGSize, perThumbnailCompletionHandler: NobjcObject | null, completionHandler: NobjcObject | null): _NSProgress;
+    fetchThumbnailsForItemIdentifiers$requestedSize$perThumbnailCompletionHandler$completionHandler$?(itemIdentifiers: _NSArray, size: CGSize, perThumbnailCompletionHandler: ((identifier: _NSString, imageData: _NSData, error: _NSError) => void) | null, completionHandler: ((error: _NSError) => void) | null): _NSProgress;
 }