objcjs-types 0.7.0 → 0.7.2

package/dist/FileProvider/NSFileProviderCreateItemOptions.d.ts

@@ -2,4 +2,4 @@ export declare const NSFileProviderCreateItemOptions: {
     readonly NSFileProviderCreateItemMayAlreadyExist: 1;
     readonly NSFileProviderCreateItemDeletionConflicted: 2;
 };
-export type NSFileProviderCreateItemOptions = (number & {}) | typeof NSFileProviderCreateItemOptions[keyof typeof NSFileProviderCreateItemOptions];
+export type NSFileProviderCreateItemOptions = (number & {}) | (typeof NSFileProviderCreateItemOptions)[keyof typeof NSFileProviderCreateItemOptions];

package/dist/FileProvider/NSFileProviderCustomAction.d.ts

@@ -6,5 +6,5 @@ export interface _NSFileProviderCustomAction {
     /**
      * Perform a custom action identified by `actionIdentifier`, on items identified by `itemIdentifiers`. Custom actions are defined in the File Provider Extension's Info.plist, under the `NSExtensionFileProviderActions` key. The format of this key is identical to actions defined in a FileProviderUI extension. Cancellations: ------------ If the NSProgress returned by this method is cancelled, the extension should call the completion handler with (NSUserCancelledError) in the NSProgress cancellation handler.
      */
-    performActionWithIdentifier$onItemsWithIdentifiers$completionHandler$?(actionIdentifier: _NSString, itemIdentifiers: _NSArray, completionHandler: ((error: _NSError) => void) | null): _NSProgress;
+    performActionWithIdentifier$onItemsWithIdentifiers$completionHandler$(actionIdentifier: _NSString, itemIdentifiers: _NSArray, completionHandler: ((error: _NSError) => void) | null): _NSProgress;
 }

package/dist/FileProvider/NSFileProviderDeleteItemOptions.d.ts

@@ -1,4 +1,4 @@
 export declare const NSFileProviderDeleteItemOptions: {
     readonly NSFileProviderDeleteItemRecursive: 1;
 };
-export type NSFileProviderDeleteItemOptions = (number & {}) | typeof NSFileProviderDeleteItemOptions[keyof typeof NSFileProviderDeleteItemOptions];
+export type NSFileProviderDeleteItemOptions = (number & {}) | (typeof NSFileProviderDeleteItemOptions)[keyof typeof NSFileProviderDeleteItemOptions];

package/dist/FileProvider/NSFileProviderDomainIdentifier.d.ts

@@ -1 +1,2 @@
-export type NSFileProviderDomainIdentifier = string;
+import type { NSStringLiteral } from "../helpers.js";
+export type NSFileProviderDomainIdentifier = NSStringLiteral<string>;

package/dist/FileProvider/NSFileProviderDomainRemovalMode.d.ts

@@ -3,4 +3,4 @@ export declare const NSFileProviderDomainRemovalMode: {
     readonly PreserveDirtyUserData: 1;
     readonly PreserveDownloadedUserData: 2;
 };
-export type NSFileProviderDomainRemovalMode = typeof NSFileProviderDomainRemovalMode[keyof typeof NSFileProviderDomainRemovalMode];
+export type NSFileProviderDomainRemovalMode = (typeof NSFileProviderDomainRemovalMode)[keyof typeof NSFileProviderDomainRemovalMode];

package/dist/FileProvider/NSFileProviderDomainState.d.ts

@@ -4,9 +4,9 @@ export interface _NSFileProviderDomainState {
     /**
      * Version of the domain. The domain version is an opaque value assigned by the provider. It is read by the system in the completion handler for createItemBasedOnTemplate, modifyItem, deleteItem and itemForIdentifier, as well as in the finish calls when enumerating the working set. The read is guaranteed to happen on the same dispatch queue the completion handler was called on. When the system discovers a change on disk, it associates that change to the currently known domain version. When that change get communicated to the extension, that version is included in the NSFileProviderRequest object passed by the system to the extension. As a consequence, the provider can use the domain version to identify the state of the system when a change was made on disk. The provider is responsible for defining when the domain version changes. When that value is updated, the provider must notify the system by signaling the working set. The system ignore any domain version that is smaller than the previously known version.
      */
-    domainVersion?(): _NSFileProviderDomainVersion;
+    domainVersion(): _NSFileProviderDomainVersion;
     /**
      * Global state of the domain. Use this dictionary to add state information to the domain. It is accessible to predicates for User Interactions, FileProvider Actions, and FileProviderUI Actions, via the top-level `domainUserInfo` context key. This dictionary must only contain key and value classes in the following list: NSString, NSNumber, NSDate, and NSPersonNameComponents. The system expects the domainVersion to be updated when the value of the userInfo property changes.
      */
-    userInfo?(): _NSDictionary;
+    userInfo(): _NSDictionary;
 }

package/dist/FileProvider/NSFileProviderDomainTestingModes.d.ts

@@ -2,4 +2,4 @@ export declare const NSFileProviderDomainTestingModes: {
     readonly NSFileProviderDomainTestingModeAlwaysEnabled: 1;
     readonly NSFileProviderDomainTestingModeInteractive: 2;
 };
-export type NSFileProviderDomainTestingModes = (number & {}) | typeof NSFileProviderDomainTestingModes[keyof typeof NSFileProviderDomainTestingModes];
+export type NSFileProviderDomainTestingModes = (number & {}) | (typeof NSFileProviderDomainTestingModes)[keyof typeof NSFileProviderDomainTestingModes];

package/dist/FileProvider/NSFileProviderEnumerating.d.ts

@@ -6,5 +6,5 @@ export interface _NSFileProviderEnumerating {
     /**
      * Create an enumerator for an item. This method is called when the user lists the content of folder it never accessed before. This can happen either when using Finder or when listing the content of the directory from a Terminal (for instance using the `ls` command line tool). The system will use the enumerator to list the children of the directory by calling -[NSFileProviderEnumerator enumerateItemsForObserver:startingAtPage:] until nil is passed to -[NSFileProviderEnumerationObserver finishEnumeratingUpToPage:]. Once this has been called, the directory and its children should be included in the working set. This is also used to subscribe to live updates for a single document. The system will keep an enumerator open in the extension on directories that are presented to the user (for instance, in Finder), and on document on which an application has a NSFilePresenter. The provider can use the existence of that enumerator as a hint that the user is actively seeing / using the item in question, and prioritize the delivery of updates on the item or its children in the working set. If returning nil, you must set the error out parameter. Working set enumerator: ----------------------- The working set enumerator is a special enumerator (NSFileProviderWorkingSetContainerItemIdentifier) the system uses to detect changes that should be synced to the disk and/or searchable in Spotlight. Because that enumerator is by definition used for change detection, the working set enumerator must implement -[NSFileProviderEnumerator enumerateChangesForObserver:fromSyncAnchor:] and -[NSFileProviderEnumerator currentSyncAnchorWithCompletionHandler:]. The system guarantees that it has a single consumer for the working set. This means there will never be two concurrent enumerations of the working set and will always do forward progress: the system will only ask for changes from the last requested sync anchor or the last returned sync anchor and the extension should be prepared for it. The expiration of the sync anchor of the working set will cause a very expensive scan of all the items known by the system. The system ingests the changes from the working set and applies the changes to the disk replicate and the spotlight index. Before ingesting the update for an item, the system will check if the enumeration of the item races against a call to createItemBasedOnTemplate, modifyItem, ... that may affect the item. If a potential race is detected, the system will call itemForItemIdentifier in order to resolve the race. If the provider exposes the key NSExtensionFileProviderAppliesChangesAtomically with value YES in its Info.plist, it is considered to apply the changes atomically, in which case the system does not need to check for potential races. Execution time: --------------- The system expects this call to complete quickly, it should build the object that will be used for enumeration and return it. The enumeration logic should happen when the system calls `-[NSFileProviderEnumerator enumerateItemsForObserver:startingAtPage:]` or `-[NSFileProviderEnumerator enumerateChangesForObserver:fromSyncAnchor:]`. Error cases: ------------ If containerItemIdentifier is NSFileProviderTrashContainerItemIdentifier and the extension does not support trashing items, then it should fail the call with the NSFeatureUnsupportedError error code from the NSCocoaErrorDomain domain. If the item requested containerItemIdentifier does not exist in the provider, the extension should fail with NSFileProviderErrorNoSuchItem. In that case, the system will consider the item has been deleted and attempt to delete the item from disk. 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 enumeration 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.
      */
-    enumeratorForContainerItemIdentifier$request$error$?(containerItemIdentifier: _NSString, request: _NSFileProviderRequest, error: NobjcObject | null): _NSFileProviderEnumerator | null;
+    enumeratorForContainerItemIdentifier$request$error$(containerItemIdentifier: _NSString, request: _NSFileProviderRequest, error: NobjcObject | null): _NSFileProviderEnumerator | null;
 }

package/dist/FileProvider/NSFileProviderEnumerationObserver.d.ts

@@ -2,12 +2,12 @@ import type { _NSArray } from "../Foundation/NSArray.js";
 import type { _NSData } from "../Foundation/NSData.js";
 import type { _NSError } from "../Foundation/NSError.js";
 export interface _NSFileProviderEnumerationObserver {
-    didEnumerateItems$?(updatedItems: _NSArray): void;
+    didEnumerateItems$(updatedItems: _NSArray): void;
     /**
      * Call this method after enumerating a full page of items. If you set a non-nil nextPage, -[NSFileProviderEnumerator enumerateItemsToObserver:startingAtPage:] might be called with nextPage to enumerate more items. This is typically driven by the user scrolling a UIDocumentBrowserViewController presenting a directory containing more child items that would fit in the view. Page data is limited to 500 bytes. Setting a larger nextPage interrupts the enumeration.
      */
-    finishEnumeratingUpToPage$?(nextPage: _NSData | null): void;
-    finishEnumeratingWithError$?(error: _NSError): void;
+    finishEnumeratingUpToPage$(nextPage: _NSData | null): void;
+    finishEnumeratingWithError$(error: _NSError): void;
     /**
      * Size of the page suggested by the system for better performance. The system will set that property to the value it considers is best suited for the current enumeration. The system can enumerate a container in various cases (container presenter in the UI, file opened in an application, materialization of the folder by the system, ...). Each case has its own performance profile. By taking into account the suggested size, the enumeration will guarantee the best user experience possible. The system enforces a maximum of 100 times the suggested size.
      */

package/dist/FileProvider/NSFileProviderEnumerator.d.ts

@@ -2,11 +2,11 @@ import type { _NSFileProviderChangeObserver } from "./NSFileProviderChangeObserv
 import type { _NSFileProviderEnumerationObserver } from "./NSFileProviderEnumerationObserver.js";
 import type { _NSData } from "../Foundation/NSData.js";
 export interface _NSFileProviderEnumerator {
-    invalidate?(): void;
+    invalidate(): void;
     /**
      * Enumerate items starting from the specified page, typically NSFileProviderInitialPageSortedByDate or NSFileProviderInitialPageSortedByName. Pagination allows large collections to be enumerated in multiple batches. The sort order specified in the initial page is important even if the enumeration results will actually be sorted again before display. If results are sorted correctly across pages, then the new results will be appended at the bottom of the list, probably not on screen, which is the best user experience. Otherwise results from the second page might be inserted in the results from the first page, causing bizarre animations. The page data should contain whatever information is needed to resume the enumeration after the previous page. If a file provider sends batches of 200 items to -[NSFileProviderEnumerationObserver didEnumerateItems:] for example, then successive pages might contain offsets in increments of 200. Execution time: --------------- This method is not expected to take more than a few seconds to complete the enumeration of a page of items. If the enumeration may not complete in a reasonable amount of time because, for instance, of bad network conditions, it is recommended to either report an error (for instance NSFileProviderErrorServerUnreachable) or return everything that is readily available and wait for the enumeration of the next page.
      */
-    enumerateItemsForObserver$startingAtPage$?(observer: _NSFileProviderEnumerationObserver, page: _NSData): void;
+    enumerateItemsForObserver$startingAtPage$(observer: _NSFileProviderEnumerationObserver, page: _NSData): void;
     /**
      * Enumerate changes starting from a sync anchor. This should enumerate /all/ changes (not restricted to a specific page) since the given sync anchor. Until the enumeration update is invalidated, a call to -[NSFileProviderManager signalEnumeratorForContainerItemIdentifier:completionHandler:] will trigger a call to enumerateFromSyncAnchor with the latest known sync anchor, giving the file provider (app or extension) a chance to notify about changes. The anchor data should contain whatever information is needed to resume enumerating changes from the previous synchronization point. A naive sync anchor might for example be the date of the last change that was sent from the server to the client, meaning that at that date, the client was in sync with all the server changes. A request to enumerate changes from that sync anchor would only return the changes that happened after that date, which are therefore changes that the client doesn't yet know about. NOTE that the change-based observation methods are marked optional for historical reasons, but are really required. System performance will be severely degraded if they are not implemented. Execution time: --------------- This method is not expected to take more than a few seconds to complete the enumeration of a batch of items. If the enumeration may not complete in a reasonable amount of time because, for instance, of bad network conditions, it is recommended to either report an error (for instance NSFileProviderErrorServerUnreachable) or return everything that is readily available and wait for the enumeration of the next batch.
      */

package/dist/FileProvider/NSFileProviderErrorCode.d.ts

@@ -24,4 +24,4 @@ export declare const NSFileProviderErrorCode: {
     readonly NSFileProviderErrorApplicationExtensionNotFound: -2014;
     readonly NSFileProviderErrorLocalVersionConflictingWithServer: -2015;
 };
-export type NSFileProviderErrorCode = typeof NSFileProviderErrorCode[keyof typeof NSFileProviderErrorCode];
+export type NSFileProviderErrorCode = (typeof NSFileProviderErrorCode)[keyof typeof NSFileProviderErrorCode];

package/dist/FileProvider/NSFileProviderExternalVolumeHandling.d.ts

@@ -3,5 +3,5 @@ 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: ((connectionError: _NSError) => void) | null): void;
+    shouldConnectExternalDomainWithCompletionHandler$(completionHandler: ((connectionError: _NSError) => void) | null): void;
 }

package/dist/FileProvider/NSFileProviderFetchContentsOptions.d.ts

@@ -1,4 +1,4 @@
 export declare const NSFileProviderFetchContentsOptions: {
     readonly StrictVersioning: 1;
 };
-export type NSFileProviderFetchContentsOptions = (number & {}) | typeof NSFileProviderFetchContentsOptions[keyof typeof NSFileProviderFetchContentsOptions];
+export type NSFileProviderFetchContentsOptions = (number & {}) | (typeof NSFileProviderFetchContentsOptions)[keyof typeof NSFileProviderFetchContentsOptions];

package/dist/FileProvider/NSFileProviderFileSystemFlags.d.ts

@@ -5,4 +5,4 @@ export declare const NSFileProviderFileSystemFlags: {
     readonly NSFileProviderFileSystemHidden: 8;
     readonly NSFileProviderFileSystemPathExtensionHidden: 16;
 };
-export type NSFileProviderFileSystemFlags = (number & {}) | typeof NSFileProviderFileSystemFlags[keyof typeof NSFileProviderFileSystemFlags];
+export type NSFileProviderFileSystemFlags = (number & {}) | (typeof NSFileProviderFileSystemFlags)[keyof typeof NSFileProviderFileSystemFlags];

package/dist/FileProvider/NSFileProviderIncrementalContentFetching.d.ts

@@ -9,5 +9,5 @@ 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: ((fileContents: _NSURL, item: _NSFileProviderItem, error: _NSError) => void) | 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/NSFileProviderItem.d.ts

@@ -15,15 +15,15 @@ export interface _NSFileProviderItem {
     /**
      * The identifier of the item. The itemIdentifier should not contain sensitive information, as it may be recorded in system logs and diagnostic files.
      */
-    itemIdentifier?(): _NSString;
+    itemIdentifier(): _NSString;
     /**
      * The parent identifier specifies the parent of the item in the hierarchy. Set to NSFileProviderRootContainerItemIdentifier for an item at the root of the user's storage. Set to the itemIdentifier of the item's parent otherwise. When enumerating the root container or a generic container, the parentItemIdentifier of the enumerated items is expected to match the enumerated item's identifier. When enumerating the working set, the parentItemIdentifier is expected to match the actual parent of the item in the hierarchy (ie. it is not NSFileProviderWorkingSetContainerItemIdentifier). The parents of trashed items and of the root item are ignored.
      */
-    parentItemIdentifier?(): _NSString;
+    parentItemIdentifier(): _NSString;
     /**
      * The file or directory name, complete with its file extension. The filename property must not be an empty string, including when the item identifier is NSFileProviderRootContainerItemIdentifier. The filename for NSFileProviderRootContainerItemIdentifier may be displayed in the user interface. Therefore it should be a user-friendly string.
      */
-    filename?(): _NSString;
+    filename(): _NSString;
     /**
      * ContentType (UTType) for the item. On macOS, items must implement contentType. On iOS, items must implement either contentType or typeIdentifier. Note that contentType is not available on iOS 13 and earlier, so typeIdentifier is required in order to target iOS 13 and earlier. When using NSFileProviderReplicatedExtension, providers must be prepared to handle the following contentType in the appropriate manner when they are passed in itemTemplates contentType to createItem/modifyItem calls: UTType.symbolicLink UTType.folder UTType.package UTType.aliasFile Changing the contentType for a given item that would result in a transition to/from a folder or to/from a symlink is not supported.
      */

package/dist/FileProvider/NSFileProviderItemCapabilities.d.ts

@@ -11,4 +11,4 @@ export declare const NSFileProviderItemCapabilities: {
     readonly AllowsContentEnumerating: 1;
     readonly AllowsAll: 63;
 };
-export type NSFileProviderItemCapabilities = (number & {}) | typeof NSFileProviderItemCapabilities[keyof typeof NSFileProviderItemCapabilities];
+export type NSFileProviderItemCapabilities = (number & {}) | (typeof NSFileProviderItemCapabilities)[keyof typeof NSFileProviderItemCapabilities];

package/dist/FileProvider/NSFileProviderItemDecorating.d.ts

@@ -4,5 +4,5 @@ export interface _NSFileProviderItemDecorating extends _NSFileProviderItem {
     /**
      * Returns an array of decorations for the item. To adopt this protocol, implement the -decorations method on your NSFileProviderItem to return valid decoration identifiers from your Info.plist.
      */
-    decorations?(): _NSArray | null;
+    decorations(): _NSArray | null;
 }

package/dist/FileProvider/NSFileProviderItemDecorationIdentifier.d.ts

@@ -1 +1,2 @@
-export type NSFileProviderItemDecorationIdentifier = string;
+import type { NSStringLiteral } from "../helpers.js";
+export type NSFileProviderItemDecorationIdentifier = NSStringLiteral<string>;

package/dist/FileProvider/NSFileProviderItemFields.d.ts

@@ -11,4 +11,4 @@ export declare const NSFileProviderItemFields: {
     readonly NSFileProviderItemExtendedAttributes: 512;
     readonly NSFileProviderItemTypeAndCreator: 1024;
 };
-export type NSFileProviderItemFields = (number & {}) | typeof NSFileProviderItemFields[keyof typeof NSFileProviderItemFields];
+export type NSFileProviderItemFields = (number & {}) | (typeof NSFileProviderItemFields)[keyof typeof NSFileProviderItemFields];

package/dist/FileProvider/NSFileProviderKnownFolderSupporting.d.ts

@@ -5,5 +5,5 @@ 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: ((arg0: _NSFileProviderKnownFolderLocations, arg1: _NSError) => void) | null): void;
+    getKnownFolderLocations$completionHandler$(knownFolders: NSFileProviderKnownFolders, completionHandler: ((arg0: _NSFileProviderKnownFolderLocations, arg1: _NSError) => void) | null): void;
 }

package/dist/FileProvider/NSFileProviderKnownFolders.d.ts

@@ -2,4 +2,4 @@ export declare const NSFileProviderKnownFolders: {
     readonly NSFileProviderDesktop: 1;
     readonly NSFileProviderDocuments: 2;
 };
-export type NSFileProviderKnownFolders = (number & {}) | typeof NSFileProviderKnownFolders[keyof typeof NSFileProviderKnownFolders];
+export type NSFileProviderKnownFolders = (number & {}) | (typeof NSFileProviderKnownFolders)[keyof typeof NSFileProviderKnownFolders];

package/dist/FileProvider/NSFileProviderManagerDisconnectionOptions.d.ts

@@ -1,4 +1,4 @@
 export declare const NSFileProviderManagerDisconnectionOptions: {
     readonly Temporary: 1;
 };
-export type NSFileProviderManagerDisconnectionOptions = (number & {}) | typeof NSFileProviderManagerDisconnectionOptions[keyof typeof NSFileProviderManagerDisconnectionOptions];
+export type NSFileProviderManagerDisconnectionOptions = (number & {}) | (typeof NSFileProviderManagerDisconnectionOptions)[keyof typeof NSFileProviderManagerDisconnectionOptions];

package/dist/FileProvider/NSFileProviderMaterializationFlags.d.ts

@@ -1,4 +1,4 @@
 export declare const NSFileProviderMaterializationFlags: {
     readonly KnownSparseRanges: 1;
 };
-export type NSFileProviderMaterializationFlags = (number & {}) | typeof NSFileProviderMaterializationFlags[keyof typeof NSFileProviderMaterializationFlags];
+export type NSFileProviderMaterializationFlags = (number & {}) | (typeof NSFileProviderMaterializationFlags)[keyof typeof NSFileProviderMaterializationFlags];

package/dist/FileProvider/NSFileProviderModifyItemOptions.d.ts

@@ -3,4 +3,4 @@ export declare const NSFileProviderModifyItemOptions: {
     readonly NSFileProviderModifyItemFailOnConflict: 2;
     readonly NSFileProviderModifyItemIsImmediateUploadRequestByPresentingApplication: 4;
 };
-export type NSFileProviderModifyItemOptions = (number & {}) | typeof NSFileProviderModifyItemOptions[keyof typeof NSFileProviderModifyItemOptions];
+export type NSFileProviderModifyItemOptions = (number & {}) | (typeof NSFileProviderModifyItemOptions)[keyof typeof NSFileProviderModifyItemOptions];

package/dist/FileProvider/NSFileProviderPartialContentFetching.d.ts

@@ -12,5 +12,5 @@ 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: ((fileContents: _NSURL, item: _NSFileProviderItem, retrievedRange: NSRange, flags: NSFileProviderMaterializationFlags, error: _NSError) => void) | 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/NSFileProviderPendingSetEnumerator.d.ts

@@ -4,13 +4,13 @@ export interface _NSFileProviderPendingSetEnumerator extends _NSFileProviderEnum
     /**
      * The version of the domain when the pending set was last refreshed by the system. This property is updated when the enumeration methods are called on the pending set enumerator. The value is initially nil.
      */
-    domainVersion?(): _NSFileProviderDomainVersion | null;
+    domainVersion(): _NSFileProviderDomainVersion | null;
     /**
      * The amount of time in seconds at which the pending set is refreshed on modifications.
      */
-    refreshInterval?(): number;
+    refreshInterval(): number;
     /**
      * This property is set to YES when the enumeration of the pending set was capped at or below its maximum size. Under normal conditions, the count of items pending sync will get lower as sync progresses, and this variable will eventually be set to NO when the pending set again includes all items pending sync.
      */
-    maximumSizeReached?(): boolean;
+    maximumSizeReached(): boolean;
 }

package/dist/FileProvider/NSFileProviderReplicatedExtension.d.ts

@@ -13,31 +13,31 @@ import type { NSFileProviderItemFields } from "./NSFileProviderItemFields.js";
 import type { NSFileProviderModifyItemOptions } from "./NSFileProviderModifyItemOptions.js";
 export interface _NSFileProviderReplicatedExtension extends _NSFileProviderEnumerating {
     /** Create a new instance of the replicated provider for the specified domain. */
-    initWithDomain$?(domain: _NSFileProviderDomain): _NSFileProviderReplicatedExtension;
+    initWithDomain$(domain: _NSFileProviderDomain): _NSFileProviderReplicatedExtension;
     /**
      * Called before the instance is discarded. Several instances of a replicated provider can be hosted by the same process, either because the user has several active domains, or because an instance got discarded and a new one is created by the system. This method is called before an instance is discarded and should make sure that all references to the instance are released so that the instance can be deallocated.
      */
-    invalidate?(): void;
+    invalidate(): void;
     /**
      * 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: ((arg0: _NSFileProviderItem, arg1: _NSError) => void) | 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: ((fileContents: _NSURL, item: _NSFileProviderItem, error: _NSError) => void) | 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: ((createdItem: _NSFileProviderItem, stillPendingFields: NSFileProviderItemFields, shouldFetchContent: boolean, error: _NSError) => void) | 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: ((item: _NSFileProviderItem, stillPendingFields: NSFileProviderItemFields, shouldFetchContent: boolean, error: _NSError) => void) | 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: ((arg0: _NSError) => void) | 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.
      */

package/dist/FileProvider/NSFileProviderSearchEnumerationObserver.d.ts

@@ -2,17 +2,17 @@ import type { _NSArray } from "../Foundation/NSArray.js";
 import type { _NSData } from "../Foundation/NSData.js";
 import type { _NSError } from "../Foundation/NSError.js";
 export interface _NSFileProviderSearchEnumerationObserver {
-    didEnumerateSearchResults$?(searchResults: _NSArray): void;
+    didEnumerateSearchResults$(searchResults: _NSArray): void;
     /**
      * Call this method after enumerating a full page of results. If you set a non-nil nextPage, -[NSFileProviderSearchEnumerator enumerateSearchResultsToObserver:startingAtPage:] might be called with nextPage to enumerate more items. Page data is limited to 500 bytes. Setting a larger nextPage interrupts the enumeration.
      */
-    finishEnumeratingUpToPage$?(nextPage: _NSData | null): void;
+    finishEnumeratingUpToPage$(nextPage: _NSData | null): void;
     /**
      * Finishing a search enumeration with an error will cause the system to stop requesting additional pages of results. The system will not retry in case of an error. It is up to the extension to decide whether to retry errors internally, in their implementation of `enumerateSearchResultsForObserver`, or to return the error to the system and end the search query.
      */
-    finishEnumeratingWithError$?(error: _NSError): void;
+    finishEnumeratingWithError$(error: _NSError): void;
     /**
      * The maximum number of results to return in a single page enumeration. If the extension returns more than this number of results in a single page enumeration, the system will crash the extension process.
      */
-    maximumNumberOfResultsPerPage?(): number;
+    maximumNumberOfResultsPerPage(): number;
 }

package/dist/FileProvider/NSFileProviderSearchEnumerator.d.ts

@@ -4,9 +4,9 @@ export interface _NSFileProviderSearchEnumerator {
     /**
      * Called when the system wants to cancel a currently running enumeration, or when the system is finished using this enumerator object. For instance, the user has changed their query, and the result of the currently running query will no longer be used by the system. Or, the system is finished using this enumerator object. The extension should cancel any outstanding requests and cleanup resources.
      */
-    invalidate?(): void;
+    invalidate(): void;
     /**
      * Enumerate search results starting from the specified page. - Parameters: - observer: The observer object, which the extension will use to provide results. - page: If a previous enumeration returned a `nextPage` on ``-[NSFileProviderSearchEnumerationObserver finishEnumeratingUpToPage:]``, the system may pass that page into the next enumeration. The page should contain whatever information is needed to resume the enumeration.
      */
-    enumerateSearchResultsForObserver$startingAtPage$?(observer: _NSFileProviderSearchEnumerationObserver, page: _NSData | null): void;
+    enumerateSearchResultsForObserver$startingAtPage$(observer: _NSFileProviderSearchEnumerationObserver, page: _NSData | null): void;
 }

package/dist/FileProvider/NSFileProviderSearchResult.d.ts

@@ -6,11 +6,11 @@ export interface _NSFileProviderSearchResult {
     /**
      * The identifier for this search result. This identifier should be usable on API calls from the ``NSFileProviderReplicatedExtension`` protocol.
      */
-    itemIdentifier?(): _NSString;
-    filename?(): _NSString;
-    creationDate?(): _NSDate | null;
-    contentModificationDate?(): _NSDate | null;
-    lastUsedDate?(): _NSDate | null;
-    contentType?(): _UTType;
-    documentSize?(): _NSNumber | null;
+    itemIdentifier(): _NSString;
+    filename(): _NSString;
+    creationDate(): _NSDate | null;
+    contentModificationDate(): _NSDate | null;
+    lastUsedDate(): _NSDate | null;
+    contentType(): _UTType;
+    documentSize(): _NSNumber | null;
 }

package/dist/FileProvider/NSFileProviderSearching.d.ts

@@ -2,5 +2,5 @@ import type { _NSFileProviderSearchEnumerator } from "./NSFileProviderSearchEnum
 import type { _NSFileProviderStringSearchRequest } from "./NSFileProviderStringSearchRequest.js";
 export interface _NSFileProviderSearching {
     /** Called by the system to retrieve search results for a user search query. */
-    searchEnumeratorForStringSearchRequest$?(request: _NSFileProviderStringSearchRequest): _NSFileProviderSearchEnumerator;
+    searchEnumeratorForStringSearchRequest$(request: _NSFileProviderStringSearchRequest): _NSFileProviderSearchEnumerator;
 }

package/dist/FileProvider/NSFileProviderServiceSource.d.ts

@@ -5,11 +5,11 @@ export interface _NSFileProviderServiceSource {
     /**
      * Return an endpoint object to allow the client application to connect to the file provider. The endpoint is retrieved from an anonymous @c NSXPCListener that the file provider creates. The file provider is in charge of accepting incoming @c NSXPCConnection's via @c -[NSXPCListenerDelegate listener:shouldAcceptNewConnection:], and setting up properties on the new connection, like its exported object and interfaces (that both the file provider and the client application have agreed on).
      */
-    makeListenerEndpointAndReturnError$?(error: NobjcObject | null): _NSXPCListenerEndpoint | null;
+    makeListenerEndpointAndReturnError$(error: NobjcObject | null): _NSXPCListenerEndpoint | null;
     /**
      * The service name that uniquely identifies the service (using reverse domain name notation for you service name is recommended).
      */
-    serviceName?(): NSFileProviderServiceName;
+    serviceName(): NSFileProviderServiceName;
     /**
      * Indicates whether access to the service is restricted. A restricted service can only be accessed by processes that can manage the domain the service is attached to. It is only accessible through `-[NSFileProviderManager getServiceWithName:itemIdentifier:completionHandler:]`
      */

package/dist/FileProvider/NSFileProviderServicing.d.ts

@@ -6,5 +6,5 @@ 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: ((arg0: _NSArray, arg1: _NSError) => void) | null): _NSProgress;
+    supportedServiceSourcesForItemIdentifier$completionHandler$(itemIdentifier: _NSString, completionHandler: ((arg0: _NSArray, arg1: _NSError) => void) | null): _NSProgress;
 }

package/dist/FileProvider/NSFileProviderTestingChildrenEnumeration.d.ts

@@ -3,7 +3,7 @@ import type { _NSFileProviderTestingOperation } from "./NSFileProviderTestingOpe
 import type { NSFileProviderTestingOperationSide } from "./NSFileProviderTestingOperationSide.js";
 export interface _NSFileProviderTestingChildrenEnumeration extends _NSFileProviderTestingOperation {
     /** The side of the operation. */
-    side?(): NSFileProviderTestingOperationSide;
+    side(): NSFileProviderTestingOperationSide;
     /** The identifier of the item. */
-    itemIdentifier?(): _NSString;
+    itemIdentifier(): _NSString;
 }

package/dist/FileProvider/NSFileProviderTestingCollisionResolution.d.ts

@@ -3,7 +3,7 @@ import type { _NSFileProviderTestingOperation } from "./NSFileProviderTestingOpe
 import type { NSFileProviderTestingOperationSide } from "./NSFileProviderTestingOperationSide.js";
 export interface _NSFileProviderTestingCollisionResolution extends _NSFileProviderTestingOperation {
     /** The side of the operation. */
-    side?(): NSFileProviderTestingOperationSide;
+    side(): NSFileProviderTestingOperationSide;
     /** The state of the item. */
-    renamedItem?(): _NSFileProviderItem;
+    renamedItem(): _NSFileProviderItem;
 }

package/dist/FileProvider/NSFileProviderTestingContentFetch.d.ts

@@ -3,7 +3,7 @@ import type { _NSFileProviderTestingOperation } from "./NSFileProviderTestingOpe
 import type { NSFileProviderTestingOperationSide } from "./NSFileProviderTestingOperationSide.js";
 export interface _NSFileProviderTestingContentFetch extends _NSFileProviderTestingOperation {
     /** The side of the operation. */
-    side?(): NSFileProviderTestingOperationSide;
+    side(): NSFileProviderTestingOperationSide;
     /** The identifier of the item. */
-    itemIdentifier?(): _NSString;
+    itemIdentifier(): _NSString;
 }

package/dist/FileProvider/NSFileProviderTestingCreation.d.ts

@@ -4,9 +4,9 @@ import type { _NSFileProviderTestingOperation } from "./NSFileProviderTestingOpe
 import type { NSFileProviderTestingOperationSide } from "./NSFileProviderTestingOperationSide.js";
 export interface _NSFileProviderTestingCreation extends _NSFileProviderTestingOperation {
     /** The target side of the operation. */
-    targetSide?(): NSFileProviderTestingOperationSide;
+    targetSide(): NSFileProviderTestingOperationSide;
     /** The description of the item. */
-    sourceItem?(): _NSFileProviderItem;
+    sourceItem(): _NSFileProviderItem;
     /** The domain version at the time the creation was discovered on the source side. */
-    domainVersion?(): _NSFileProviderDomainVersion | null;
+    domainVersion(): _NSFileProviderDomainVersion | null;
 }

package/dist/FileProvider/NSFileProviderTestingDeletion.d.ts

@@ -5,13 +5,13 @@ import type { _NSFileProviderTestingOperation } from "./NSFileProviderTestingOpe
 import type { NSFileProviderTestingOperationSide } from "./NSFileProviderTestingOperationSide.js";
 export interface _NSFileProviderTestingDeletion extends _NSFileProviderTestingOperation {
     /** The target side of the operation. */
-    targetSide?(): NSFileProviderTestingOperationSide;
+    targetSide(): NSFileProviderTestingOperationSide;
     /** The identifier of the source item. */
-    sourceItemIdentifier?(): _NSString;
+    sourceItemIdentifier(): _NSString;
     /** The identifier of the target item. */
-    targetItemIdentifier?(): _NSString;
+    targetItemIdentifier(): _NSString;
     /** The version of the target item on top of which the deletion is applied */
-    targetItemBaseVersion?(): _NSFileProviderItemVersion;
+    targetItemBaseVersion(): _NSFileProviderItemVersion;
     /** The domain version at the time the change was discovered on the source side. */
-    domainVersion?(): _NSFileProviderDomainVersion | null;
+    domainVersion(): _NSFileProviderDomainVersion | null;
 }

package/dist/FileProvider/NSFileProviderTestingIngestion.d.ts

@@ -4,9 +4,9 @@ import type { _NSFileProviderTestingOperation } from "./NSFileProviderTestingOpe
 import type { NSFileProviderTestingOperationSide } from "./NSFileProviderTestingOperationSide.js";
 export interface _NSFileProviderTestingIngestion extends _NSFileProviderTestingOperation {
     /** Side of the event. */
-    side?(): NSFileProviderTestingOperationSide;
+    side(): NSFileProviderTestingOperationSide;
     /** Identifier of the affected item. */
-    itemIdentifier?(): _NSString;
+    itemIdentifier(): _NSString;
     /** The metadata of the item. This will be nil if the item is being deleted. */
-    item?(): _NSFileProviderItem | null;
+    item(): _NSFileProviderItem | null;
 }

package/dist/FileProvider/NSFileProviderTestingLookup.d.ts

@@ -3,7 +3,7 @@ import type { _NSFileProviderTestingOperation } from "./NSFileProviderTestingOpe
 import type { NSFileProviderTestingOperationSide } from "./NSFileProviderTestingOperationSide.js";
 export interface _NSFileProviderTestingLookup extends _NSFileProviderTestingOperation {
     /** Side of the event. */
-    side?(): NSFileProviderTestingOperationSide;
+    side(): NSFileProviderTestingOperationSide;
     /** Identifier of the affected item. */
-    itemIdentifier?(): _NSString;
+    itemIdentifier(): _NSString;
 }