objcjs-types 0.6.4 → 0.7.1

package/dist/DiscRecording/DRTrackDataProduction.d.ts

@@ -6,37 +6,37 @@ export interface _DRTrackDataProduction {
     /**
      * @method estimateLengthOfTrack: @abstract Estimates the size of the track to be burned. @discussion This message is sent outside of a burn cycle in response to a -estimateLength message sent to the track. @param track The track object for which to estimate the size @result The number of blocks of data that the track will occupy. The estimate should be reasonably accurate, and no smaller than the actual size that will be needed.
      */
-    estimateLengthOfTrack$?(track: _DRTrack): number;
+    estimateLengthOfTrack$(track: _DRTrack): number;
     /**
      * @method prepareTrack:forBurn:toMedia: @abstract Prepares the track for burning. @discussion Called before any burning starts. Do any sort of setup that needs to be performed (such as opening files). This method can calculate and update the exact track length that will be burned. Since this method is called before the laser is turned on, this method can perform time consuming tasks. @param track The track object being burned @param burn The burn object controlling the burn @param mediaInfo The media being burned to. This is the same dictionary as returned by @link //apple_ref/occ/instm/DRDevice/status -[DRDevice status] @/link. @result <i>YES</i> to indicate that the burn should proceed and <i>NO</i> to indicate a failure occurred.
      */
-    prepareTrack$forBurn$toMedia$?(track: _DRTrack, burn: _DRBurn, mediaInfo: _NSDictionary): boolean;
+    prepareTrack$forBurn$toMedia$(track: _DRTrack, burn: _DRBurn, mediaInfo: _NSDictionary): boolean;
     /**
      * @method cleanupTrackAfterBurn: @abstract Cleans up the track after the burn completes. @discussion Called after burning is complete. Typically you'll clean up what was setup in <b>prepareTrackForBurn</b>. Since this method is called after the laser is turned off and the burn is finished, this method can perform time consuming tasks. @param track The track object being burned @result <i>YES</i> to indicate that the burn should proceed and <i>NO</i> to indicate a failure occurred.
      */
-    cleanupTrackAfterBurn$?(track: _DRTrack): void;
+    cleanupTrackAfterBurn$(track: _DRTrack): void;
     /**
      * @method producePreGapForTrack:intoBuffer:length:atAddress:blockSize:ioFlags: @abstract Produces the pregap data. @discussion This method is called to obtain data for the track's pregap. If the @link DRPreGapLengthKey DRPreGapLengthKey @/link key is present in the track properties, the track producer will be asked for the pregap data first. If the producer implements this selector, then it's the responsibility of the producer to provide data for the pregap, otherwise that length of silence will be produced by DiscRecording. The buffer passed in will be a multiple of blockSize (bufferLength == blockSize * N, where N > 1) and should be filled as full as possible with data. address is the sector address on the disc from the start of the track that is the buffer will be written to. Since while burning, keeping the drive's buffer full is of utmost importance, you should not perform lengthy operations or block for data in this method. This method should return the number of bytes actually in the buffer or 0 to indicate that there was an error producing the data.. @param track The track object being burned @param buffer The buffer to place data into @param bufferLength The length of buffer @param address The on-disc address of where data will be written @param blockSize the size of each block on the disc. It's best to return a multiple of this size. @param flags flags @result The number of bytes produced.
      */
-    producePreGapForTrack$intoBuffer$length$atAddress$blockSize$ioFlags$?(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): number;
+    producePreGapForTrack$intoBuffer$length$atAddress$blockSize$ioFlags$(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): number;
     /**
      * @method produceDataForTrack:intoBuffer:length:atAddress:blockSize:ioFlags: @abstract Produces the track data. @discussion This method is called many times over the course of a burn to obtain data for the track. The buffer passed in will be a multiple of blockSize (bufferLength == blockSize * N, where N > 1) and should be filled as full as possible with data. address is the sector address on the disc from the start of the track that is the buffer will be written to. Since while burning, keeping the drive's buffer full is of utmost importance, you should not perform lengthy operations or block for data in this method. This method should return the number of bytes actually in the buffer or 0 to indicate that there was an error producing the data.. @param track The track object being burned @param buffer The buffer to place data into @param bufferLength The length of buffer @param address The on-disc address of where data will be written @param blockSize the size of each block on the disc. It's best to return a multiple of this size. @param flags flags @result The number of bytes produced.
      */
-    produceDataForTrack$intoBuffer$length$atAddress$blockSize$ioFlags$?(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): number;
+    produceDataForTrack$intoBuffer$length$atAddress$blockSize$ioFlags$(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): number;
     /**
      * @method prepareTrackForVerification: @abstract Prepare the track to be verified. @discussion This method is called after the burn complets writing data to disc and before verification phase starts. Now would be a good time to prepare to produce data again by rewinding to the start of files, etc. @param track The track object being burned @result <i>YES</i> to indicate that the verification should proceed and <i>NO</i> to indicate a failure occurred.
      */
-    prepareTrackForVerification$?(track: _DRTrack): boolean;
+    prepareTrackForVerification$(track: _DRTrack): boolean;
     /**
      * @method verifyPreGapForTrack:inBuffer:length:atAddress:blockSize:ioFlags: @abstract Checks the integrity track pregap after a burn. @discussion If the class implementing this method asks for a verification type of @link DRVerificationTypeReceiveData DRVerificationTypeReceiveData @/link, then a series of calls to this method will start. It's up to the class to reproduce the pregap again and compare it to the data passed in buffer. The buffer passed in will be a multiple of blockSize (bufferLength == blockSize * N, where N > 1). address is the sector address on the disc from the start of the track that is the buffer was written to. @param track The track object being burned @param buffer The data read in from the track to compare with @param bufferLength The length of buffer @param address The on-disc address of where data will was read from. @param blockSize the size of each block on the disc. It's best to return a multiple of this size. @param flags flags @result <i>YES</i> to indicate that the data compared successfully and <i>NO</i> to indicate a failure occurred.
      */
-    verifyPreGapForTrack$inBuffer$length$atAddress$blockSize$ioFlags$?(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): boolean;
+    verifyPreGapForTrack$inBuffer$length$atAddress$blockSize$ioFlags$(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): boolean;
     /**
      * @method verifyDataForTrack:inBuffer:length:atAddress:blockSize:ioFlags: @abstract Cleans up the track after the burn completes. @discussion If the class implementing this method asks for a verification type of @link DRVerificationTypeReceiveData DRVerificationTypeReceiveData @/link, then a series of calls to this method will start. It's up to the class to reproduce the data again and compare it to the data passed in buffer. The buffer passed in will be a multiple of blockSize (bufferLength == blockSize * N, where N > 1). address is the sector address on the disc from the start of the track that is the buffer was written to. @param track The track object being burned @param buffer The data read in from the track to compare with @param bufferLength The length of buffer @param address The on-disc address of where data will was read from. @param blockSize the size of each block on the disc. It's best to return a multiple of this size. @param flags flags @result <i>YES</i> to indicate that the data compared successfully and <i>NO</i> to indicate a failure occurred.
      */
-    verifyDataForTrack$inBuffer$length$atAddress$blockSize$ioFlags$?(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): boolean;
+    verifyDataForTrack$inBuffer$length$atAddress$blockSize$ioFlags$(track: _DRTrack, buffer: string, bufferLength: number, address: number, blockSize: number, flags: NobjcObject): boolean;
     /**
      * @method cleanupTrackAfterVerification: @abstract Cleans up the track after the verification completes. @discussion Once the verification phase is complete, this method is called. The class implementing the method has a chance to do anything up to and including failing the verification. @param track The track object being burned @result Return <i>YES</i> to indicate success, <i>NO</i> to indicate failure.
      */
-    cleanupTrackAfterVerification$?(track: _DRTrack): boolean;
+    cleanupTrackAfterVerification$(track: _DRTrack): boolean;
 }

package/dist/ExternalAccessory/EAWiFiUnconfiguredAccessoryBrowserDelegate.d.ts

@@ -7,17 +7,17 @@ export interface _EAWiFiUnconfiguredAccessoryBrowserDelegate {
     /**
      * @method accessoryBrowser:didUpdateState: @discussion Invoked whenever the EAWiFiUnconfiguredAccessoryBrowser's state has changed. @param browser The EAWiFiUnconfiguredAccessoryBrowser instance generating the event. @param state The current state of the EAWiFiUnconfiguredAccessoryBrowser.
      */
-    accessoryBrowser$didUpdateState$?(browser: _EAWiFiUnconfiguredAccessoryBrowser, state: EAWiFiUnconfiguredAccessoryBrowserState): void;
+    accessoryBrowser$didUpdateState$(browser: _EAWiFiUnconfiguredAccessoryBrowser, state: EAWiFiUnconfiguredAccessoryBrowserState): void;
     /**
      * @method accessoryBrowser:didFindUnconfiguredAccessories: @discussion Invoked whenever the EAWiFiUnconfiguredAccessoryBrowser has found new unconfigured accessories that match the filter predicate defined when starting the search. @param browser The EAWiFiUnconfiguredAccessoryBrowser instance generating the event. @param accessories The set of EAWiFiUnconfiguredAccessory objects that have been found since the last update.
      */
-    accessoryBrowser$didFindUnconfiguredAccessories$?(browser: _EAWiFiUnconfiguredAccessoryBrowser, accessories: _NSSet): void;
+    accessoryBrowser$didFindUnconfiguredAccessories$(browser: _EAWiFiUnconfiguredAccessoryBrowser, accessories: _NSSet): void;
     /**
      * @method accessoryBrowser:didRemoveUnconfiguredAccessories: @discussion Invoked whenever the EAWiFiUnconfiguredAccessoryBrowser has removed unconfigured accessories from the scan results that match the filter predicate defined when starting the search. @param browser The EAWiFiUnconfiguredAccessoryBrowser instance generating the event. @param accessories The set of EAWiFiUnconfiguredAccessory objects that have been removed from the scan results since the last update.
      */
-    accessoryBrowser$didRemoveUnconfiguredAccessories$?(browser: _EAWiFiUnconfiguredAccessoryBrowser, accessories: _NSSet): void;
+    accessoryBrowser$didRemoveUnconfiguredAccessories$(browser: _EAWiFiUnconfiguredAccessoryBrowser, accessories: _NSSet): void;
     /**
      * @method accessoryBrowser:didFinishConfiguringAccessory:withStatus: @discussion Invoked whenever the EAWiFiUnconfiguredAccessoryBrowser has completed configuring the selected EAWiFiUnconfiguredAccessory. @param browser The EAWiFiUnconfiguredAccessoryBrowser instance generating the event. @param accessory The EAWiFiUnconfiguredAccessory whose configuration process has completed. @param status The status of the configuration process that has completed.
      */
-    accessoryBrowser$didFinishConfiguringAccessory$withStatus$?(browser: _EAWiFiUnconfiguredAccessoryBrowser, accessory: _EAWiFiUnconfiguredAccessory, status: EAWiFiUnconfiguredAccessoryConfigurationStatus): void;
+    accessoryBrowser$didFinishConfiguringAccessory$withStatus$(browser: _EAWiFiUnconfiguredAccessoryBrowser, accessory: _EAWiFiUnconfiguredAccessory, status: EAWiFiUnconfiguredAccessoryConfigurationStatus): void;
 }

package/dist/FSKit/FSFileSystemBase.d.ts

@@ -5,10 +5,10 @@ export interface _FSFileSystemBase {
     /**
      * Wipes existing file systems on the specified resource. This method wraps the `wipefs` functionality from `libutil`. For more information, see the `man` page for `wipefs`. - Parameters: - resource: The ``FSBlockDeviceResource`` to wipe. - completion: A block or closure that executes after the wipe operation completes. The completion handler receives a single parameter indicating any error that occurs during the operation. If the value is `nil`, the wipe operation succeeded.
      */
-    wipeResource$completionHandler$?(resource: _FSBlockDeviceResource, completion: ((error: _NSError) => void) | null): void;
+    wipeResource$completionHandler$(resource: _FSBlockDeviceResource, completion: ((error: _NSError) => void) | null): void;
     /**
      * The status of the file system container, indicating its readiness and activity. A file system container starts in the ``FSContainerState/notReady`` state, and then transitions to the other values of the ``FSContainerState`` enumeration. The following diagram illustrates the possible state transitions. ![A flow diagram of four possible container states. The initial state, notReady, can transition to ready or blocked. The ready state can transition back to not ready, or to blocked or active. The blocked state can transition to ready or not ready. The active state can transition back to ready or to not ready.](fs-file-system-base) Your file system implementation updates this property as it changes state. Many events and operations may trigger a state transition, and some transitions depend on a specific file system's design. When using ``FSBlockDeviceResource``, implement the following common state transitions: * Calling `loadResource` transitions the state out of ``FSContainerState/notReady``. For all block device file systems, this operation changes the state to either ``FSContainerState/ready`` or ``FSContainerState/blocked``. * Calling `unloadResource` transitions to the ``FSContainerState/notReady`` state, as does device termination. * Transitioning from ``FSContainerState/blocked`` to ``FSContainerState/ready`` occurs as a result of resolving the underlying block favorably. * Transitioning from ``FSContainerState/ready`` to ``FSContainerState/blocked`` is unusal, but valid. * Transitioning between ``FSContainerState/ready`` and ``FSContainerState/active`` can result from maintenance operations such as ``FSManageableResourceMaintenanceOperations/startCheckWithTask:options:error:``. For a ``FSUnaryFileSystem``, this transition can also occur when activating or deactivating the container's single volume.
      */
-    containerStatus?(): _FSContainerStatus;
-    setContainerStatus$?(value: _FSContainerStatus): void;
+    containerStatus(): _FSContainerStatus;
+    setContainerStatus$(value: _FSContainerStatus): void;
 }

package/dist/FSKit/FSManageableResourceMaintenanceOperations.d.ts

@@ -6,9 +6,9 @@ export interface _FSManageableResourceMaintenanceOperations {
     /**
      * Starts checking the file system with the given options. - Parameters: - task: A task object you use to communicate back to the client. - options: Options for performing the check. - error: In Objective-C, a pointer to an <doc://com.apple.documentation/documentation/Foundation/NSError>. Populate this with any error that occurs when starting the check. In Swift, throw an <doc://com.apple.documentation/documentation/Swift/Error> instead. - Returns: An <doc://com.apple.documentation/documentation/Foundation/NSProgress> object that you use to update progress as the check operation progresses. Return `nil` if starting the file system check encountered an error.
      */
-    startCheckWithTask$options$error$?(task: _FSTask, options: _FSTaskOptions, error: NobjcObject | null): _NSProgress | null;
+    startCheckWithTask$options$error$(task: _FSTask, options: _FSTaskOptions, error: NobjcObject | null): _NSProgress | null;
     /**
      * Starts formatting the file system with the given options. - Parameters: - task: A task object you use to communicate back to the client. - options: Options for performing the format. - error: In Objective-C, a pointer to an <doc://com.apple.documentation/documentation/Foundation/NSError>. Populate this with any error that occurs when starting the format. In Swift, throw an <doc://com.apple.documentation/documentation/Swift/Error> instead. - Returns: An <doc://com.apple.documentation/documentation/Foundation/NSProgress> object that you use to update progress as the format operation progresses. Return `nil` if starting to format the file system encountered an error.
      */
-    startFormatWithTask$options$error$?(task: _FSTask, options: _FSTaskOptions, error: NobjcObject | null): _NSProgress | null;
+    startFormatWithTask$options$error$(task: _FSTask, options: _FSTaskOptions, error: NobjcObject | null): _NSProgress | null;
 }

package/dist/FSKit/FSUnaryFileSystemOperations.d.ts

@@ -7,15 +7,15 @@ export interface _FSUnaryFileSystemOperations {
     /**
      * Requests that the file system probe the specified resource. Implement this method to indicate whether the resource is recognizable and usable. - Parameters: - resource: The ``FSResource`` to probe. - reply: A block or closure that your implementation invokes when it finishes the probe or encounters an error. Pass an instance of ``FSProbeResult`` with probe results as the first parameter if your probe operation succeeds. If probing fails, pass an error as the second parameter.
      */
-    probeResource$replyHandler$?(resource: _FSResource, reply: ((result: _FSProbeResult, error: _NSError) => void) | null): void;
+    probeResource$replyHandler$(resource: _FSResource, reply: ((result: _FSProbeResult, error: _NSError) => void) | null): void;
     /**
      * Requests that the file system load a resource and present it as a volume. Implement this method by inspecting the provided resource and verifying it uses a supported format. If the resource does use a supported format, create a subclass of `FSVolume`, clear the container error state, and invoke the `reply` callback, passing your volume as a parameter. If loading can't proceed, invoke `reply` and send an appropriate error as the second parameter. - Parameters: - resource: An ``FSResource`` to load. - options: An ``FSTaskOptions`` object specifying options to apply when loading the resource. An ``FSUnaryFileSystem`` supports two options: `-f` for "force" and `--rdonly` for read-only. The file system must remember if the read-only option is present. - reply: A block or closure that your implementation invokes when it finishes setting up or encounters an error. Pass a subclass of `FSVolume` as the first parameter if loading succeeds. If loading fails, pass an error as the second parameter.
      */
-    loadResource$options$replyHandler$?(resource: _FSResource, options: _FSTaskOptions, reply: ((volume: _FSVolume, err: _NSError) => void) | null): void;
+    loadResource$options$replyHandler$(resource: _FSResource, options: _FSTaskOptions, reply: ((volume: _FSVolume, err: _NSError) => void) | null): void;
     /**
      * Requests that the file system unload the specified resource. - Parameters: - resource: An ``FSResource`` to unload. - options: An ``FSTaskOptions`` object specifying options to apply when unloading the resource. - reply: A block or closure that your implementation invokes when it finishes unloading or encounters an error. If unloading fails, pass an error as the parameter to describe the problem. Otherwise, pass `nil`.
      */
-    unloadResource$options$replyHandler$?(resource: _FSResource, options: _FSTaskOptions, reply: ((err: _NSError) => void) | null): void;
+    unloadResource$options$replyHandler$(resource: _FSResource, options: _FSTaskOptions, reply: ((err: _NSError) => void) | null): void;
     /**
      * Notifies you that the system finished loading your file system extension. The system performs this callback after the main run loop starts and before receiving the first message from the FSKit daemon. Implement this method if you want to perform any setup prior to receiving FSKit callbacks.
      */

package/dist/FSKit/FSVolumeAccessCheckOperations.d.ts

@@ -5,7 +5,7 @@ export interface _FSVolumeAccessCheckOperations {
     /**
      * Checks whether the file system allows access to the given item. - Parameters: - theItem: The item for which to check access. - access: A mask indicating a set of access types for which to check. - reply: A block or closure to indicate success or failure. If the access check succeeds, pass a Boolean value to indicate whether the file system grants access, followed by a `nil` error. If the access check fails, pass the relevant error as the second parameter; FSKit ignores the Boolean parameter in this case. For an `async` Swift implementation, there's no reply handler; simply return the `Bool` or throw an error.
      */
-    checkAccessToItem$requestedAccess$replyHandler$?(theItem: _FSItem, access: FSAccessMask, reply: ((shouldAllowAccess: boolean, error: _NSError) => void) | null): void;
+    checkAccessToItem$requestedAccess$replyHandler$(theItem: _FSItem, access: FSAccessMask, reply: ((shouldAllowAccess: boolean, error: _NSError) => void) | null): void;
     /**
      * A Boolean value that instructs FSKit not to call this protocol's methods, even if the volume conforms to it. FSKit reads this value after the file system replies to the `loadResource` message. Changing the returned value during the runtime of the volume has no effect.
      */

package/dist/FSKit/FSVolumeItemDeactivation.d.ts

@@ -5,9 +5,9 @@ export interface _FSVolumeItemDeactivation {
     /**
      * Notifies the file system that the kernel is no longer making immediate use of the given item. This method gives a file system a chance to release resources associated wtih an item. However, this method prescribes no specific action; it's acceptable to defer all reclamation until ``FSVolume/Operations/reclaimItem(_:replyHandler:)``. This method is the equivalent of VFS's `VNOP_INACTIVE`. FSKit restricts calls to this method based on the current value of ``FSVolume/ItemDeactivation/itemDeactivationPolicy``. - Parameters: - item: The item to deactivate. - reply: A block or closure to indicate success or failure. If deactivation fails, pass an error as the one parameter to the reply handler. If deactivation succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    deactivateItem$replyHandler$?(item: _FSItem, reply: ((error: _NSError) => void) | null): void;
+    deactivateItem$replyHandler$(item: _FSItem, reply: ((error: _NSError) => void) | null): void;
     /**
      * A property that tells FSKit to which types of items the deactivation applies, if any. FSKit reads this value after the file system replies to the `loadResource` message. Changing the returned value during the runtime of the volume has no effect.
      */
-    itemDeactivationPolicy?(): FSItemDeactivationOptions;
+    itemDeactivationPolicy(): FSItemDeactivationOptions;
 }

package/dist/FSKit/FSVolumeKernelOffloadedIOOperations.d.ts

@@ -12,19 +12,19 @@ export interface _FSVolumeKernelOffloadedIOOperations {
     /**
      * Maps a file's disk space into extents, allowing the kernel to perform I/O with that space. FSKit calls this method when the kernel needs to get a mapping of logical-to-physical offsets of the file's data. This call may occur as part of an I/O operation on the file, or just to get the mapping as part of a `fcntl(F_LOG2PHYS)` system call. In the case of an I/O operation on the file, `operationID` has a nonzero value; a future call to ``completeIO(for:offset:length:status:flags:operationID:replyHandler:)`` uses the same `operationID` to indicate which operation it completes. In the case of a `fcntl(F_LOG2PHYS)` system call, the `operationID` parameter is `0` (Objective-C) or ``FSOperationID/unspecified`` (Swift). In both cases the kernel retains the mapping, and it may perform I/O to this range (or a part of it) at any time. If satisfying a blockmap request requires more extents than `packer` can handle, FSKit makes additional calls to this method with the same operation ID to collect the remainder. - Parameters: - file: The file for which to map disk space. - offset: The starting logical offset of the range to be mapped (in bytes). - length: The length of the range to be mapped (in bytes). - flags: Flags that affect the behavior of the blockmap operation. - operationID: A unique identifier of the blockmap call. Any value other than `0` (Objective-C) or ``FSOperationID/unspecified`` (Swift) indicates the beginning of an I/O operation. A value of `0` or ``FSOperationID/unspecified`` indicates the kernel maps the file without performing I/O. In this case, FSKit doesn't perform a corresponding call to ``completeIO(for:offset:length:status:flags:operationID:replyHandler:)``. - packer: An extent packer you use to pack the requested range of the file's allocated disk space. FSKit sends all of the packed extents to the kernel when it invokes `reply`. - reply: A block or closure to indicate success or failure. If mapping fails, pass an error as the one parameter to the reply handler. If mapping succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    blockmapFile$offset$length$flags$operationID$packer$replyHandler$?(file: _FSItem, offset: NobjcObject, length: number, flags: FSBlockmapFlags, operationID: FSOperationID, packer: _FSExtentPacker, reply: ((error: _NSError) => void) | null): void;
+    blockmapFile$offset$length$flags$operationID$packer$replyHandler$(file: _FSItem, offset: NobjcObject, length: number, flags: FSBlockmapFlags, operationID: FSOperationID, packer: _FSExtentPacker, reply: ((error: _NSError) => void) | null): void;
     /**
      * Completes an I/O operation for a given file. Implement this method by updating a file's metadata, such as its size and modification time. FSKit may call this method without an earlier call to ``blockmapFile(_:offset:length:flags:operationID:packer:replyHandler:)``. In this case, the `operationID` is `0` (Objective-C) or ``FSOperationID/unspecified`` (Swift). - Parameters: - file: The file for which the I/O operation completed. - offset: The starting logical offset at which I/O started. - length: The length of the I/O range (in bytes). - status: Any error that occurred during the operation. If no error occurred, this parameter is `nil`. - flags: Flags that affect the behavior of the complete I/O operation. - operationID: A unique identifier of the blockmap call. Any value other than `0` (Objective-C) or ``FSOperationID/unspecified`` (Swift) corresponds to a previous call to ``blockmapFile(_:offset:length:flags:operationID:packer:replyHandler:)`` with the same `operationID`. - reply: A block or closure to indicate success or failure. If completing I/O fails, pass an error as the one parameter to the reply handler. If completing I/O succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    completeIOForFile$offset$length$status$flags$operationID$replyHandler$?(file: _FSItem, offset: NobjcObject, length: number, status: _NSError, flags: FSCompleteIOFlags, operationID: FSOperationID, reply: ((error: _NSError) => void) | null): void;
+    completeIOForFile$offset$length$status$flags$operationID$replyHandler$(file: _FSItem, offset: NobjcObject, length: number, status: _NSError, flags: FSCompleteIOFlags, operationID: FSOperationID, reply: ((error: _NSError) => void) | null): void;
     /**
      * Creates a new file item and map its disk space. This method allows the module to opportunistically supply extents, avoiding future calls to ``blockmapFile(_:offset:length:flags:operationID:packer:replyHandler:)``. Only perform this technique opportunistically. In particular, don't perform additional I/O to fetch extent data. Packing extents in this method requires that `attributes` defines a size greater than 0. An implementation that doesn't supply the extents can ignore the packer and call the corresponding method in the ``FSVolume/Operations`` protocol, ``FSVolume/Operations/createItem(named:type:inDirectory:attributes:replyHandler:)``. - Parameters: - name: The new file's name. - directory: The directory in which to create the file. - attributes: Attributes to apply to the new file. - packer: An extent packer you use to pack the file's allocated disk space. - reply: A block or closure to indicate success or failure. If creation succeeds, pass the newly created ``FSItem`` and its ``FSFileName``, along with a `nil` error. If creation fails, pass the relevant error as the third parameter; FSKit ignores any ``FSItem`` or ``FSFileName`` in this case. For an `async` Swift implementation, there's no reply handler; instead, return a tuple of the ``FSItem`` and its ``FSFileName`` or throw an error.
      */
-    createFileNamed$inDirectory$attributes$packer$replyHandler$?(name: _FSFileName, directory: _FSItem, attributes: _FSItemSetAttributesRequest, packer: _FSExtentPacker, reply: ((newFile: _FSItem, newFileName: _FSFileName, error: _NSError) => void) | null): void;
+    createFileNamed$inDirectory$attributes$packer$replyHandler$(name: _FSFileName, directory: _FSItem, attributes: _FSItemSetAttributesRequest, packer: _FSExtentPacker, reply: ((newFile: _FSItem, newFileName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Looks up an item within a directory and maps its disk space. This method allows the module to opportunistically supply extents, avoiding future calls to ``blockmapFile(_:offset:length:flags:operationID:packer:replyHandler:)``. Only perform this technique opportunistically. In particular, don't perform additional I/O to fetch extent data. - Parameters: - name: The name of the file to look up. - directory: The directory in which to look up the file. - packer: An extent packer you use to pack the file's allocated disk space. - reply: A block or closure to indicate success or failure. If lookup succeeds, pass the found ``FSItem`` and its ``FSFileName``, along with a `nil` error. If lookup fails, pass the relevant error as the third parameter; FSKit ignores any ``FSItem`` or ``FSFileName`` in this case. For an `async` Swift implementation, there's no reply handler; instead, return a tuple of the ``FSItem`` and its ``FSFileName`` or throw an error.
      */
-    lookupItemNamed$inDirectory$packer$replyHandler$?(name: _FSFileName, directory: _FSItem, packer: _FSExtentPacker, reply: ((theItem: _FSItem, itemName: _FSFileName, error: _NSError) => void) | null): void;
+    lookupItemNamed$inDirectory$packer$replyHandler$(name: _FSFileName, directory: _FSItem, packer: _FSExtentPacker, reply: ((theItem: _FSItem, itemName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Preallocates and maps disk space for the given file. This method allows the module to opportunistically supply extents, avoiding future calls to ``blockmapFile(_:offset:length:flags:operationID:packer:replyHandler:)``. > Important: Only implement this method if your file system conforms to ``FSVolume/PreallocateOperations``. - Parameters: - file: The item for which to preallocate space. - offset: The offset from which to allocate. - length: The length of the space in bytes. - flags: Flags that affect the preallocation behavior. - packer: An extent packer you use to pack the file's preallocated disk space. - reply: A block or closure to indicate success or failure. If preallocation succeeds, pass the amount of bytes allocated and a nil error. If preallocation fails, pass the relevant error as the second parameter; FSKit ignores any byte count in this case. For an `async` Swift implementation, there’s no reply handler; simply return the allocated byte count or throw an error.
      */

package/dist/FSKit/FSVolumeOpenCloseOperations.d.ts

@@ -5,11 +5,11 @@ export interface _FSVolumeOpenCloseOperations {
     /**
      * Opens a file for access. - Parameters: - item: The item to open. - modes: The set of mode flags to open the item with. - reply: A block or closure to indicate success or failure. If opening fails, pass an error as the one parameter to the reply handler. If opening succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    openItem$withModes$replyHandler$?(item: _FSItem, modes: FSVolumeOpenModes, reply: ((error: _NSError) => void) | null): void;
+    openItem$withModes$replyHandler$(item: _FSItem, modes: FSVolumeOpenModes, reply: ((error: _NSError) => void) | null): void;
     /**
      * Closes a file from further access. - Parameters: - item: The item to close. - modes: The set of mode flags to keep after this close. - reply: A block or closure to indicate success or failure. If closing fails, pass an error as the one parameter to the reply handler. If closing succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    closeItem$keepingModes$replyHandler$?(item: _FSItem, modes: FSVolumeOpenModes, reply: ((error: _NSError) => void) | null): void;
+    closeItem$keepingModes$replyHandler$(item: _FSItem, modes: FSVolumeOpenModes, reply: ((error: _NSError) => void) | null): void;
     /**
      * A Boolean value that instructs FSKit not to call this protocol's methods, even if the volume conforms to it. FSKit reads this value after the file system replies to the `loadResource` message. Changing the returned value during the runtime of the volume has no effect.
      */

package/dist/FSKit/FSVolumeOperations.d.ts

@@ -16,71 +16,71 @@ export interface _FSVolumeOperations extends _FSVolumePathConfOperations {
     /**
      * Mounts this volume, using the specified options. FSKit calls this method as a signal that some process is trying to mount this volume. Your file system receives a call to ``activate(options:replyHandler:)`` prior to receiving any mount calls. - Parameters: - options: Options to apply to the mount. These can include security-scoped file paths. There are no defined options currently. - reply: A block or closure to indicate success or failure. If mounting fails, pass an error as the one parameter to the reply handler. If mounting succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply return normally.
      */
-    mountWithOptions$replyHandler$?(options: _FSTaskOptions, reply: ((error: _NSError) => void) | null): void;
+    mountWithOptions$replyHandler$(options: _FSTaskOptions, reply: ((error: _NSError) => void) | null): void;
     /**
      * Unmounts this volume. Clear and flush all cached state in your implementation of this method. - Parameters: - reply: A block or closure to indicate success or failure. If unmounting fails, pass an error as the one parameter to the reply handler. If unmounting succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply return normally.
      */
-    unmountWithReplyHandler$?(reply: () => void): void;
+    unmountWithReplyHandler$(reply: () => void): void;
     /**
      * Synchronizes the volume with its underlying resource. After calling this method, FSKit assumes that the volume has sent all pending I/O or metadata to its resource. - Parameters: - flags: Timing flags, as defined in `mount.h.` These flags let the file system know whether to run the operation in a blocking or nonblocking fashion. - reply: A block or closure to indicate success or failure. If synchronization fails, pass an error as the one parameter to the reply handler. If synchronization succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    synchronizeWithFlags$replyHandler$?(flags: FSSyncFlags, reply: ((error: _NSError) => void) | null): void;
+    synchronizeWithFlags$replyHandler$(flags: FSSyncFlags, reply: ((error: _NSError) => void) | null): void;
     /**
      * Fetches attributes for the given item. For file systems that don't support hard links, set ``FSItemAttributes/linkCount`` to `1` for regular files and symbolic links. If the item's `bsdFlags` contain the `UF_COMPRESSED` flag, your file system returns the uncompressed size of the file. - Parameters: - desiredAttributes: A requested set of attributes to get. The implementation inspects the request's ``FSItemGetAttributesRequest/wantedAttributes`` to determine which attributes to populate. - item: The item to get attributes for. - reply: A block or closure to indicate success or failure. If getting attributes succeeds, pass an ``FSItemAttributes`` with the requested attributes populated and a `nil` error. If getting attributes fails, pass the relevant error as the second parameter; FSKit ignores any ``FSItemAttributes`` in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSItemAttributes`` or throw an error.
      */
-    getAttributes$ofItem$replyHandler$?(desiredAttributes: _FSItemGetAttributesRequest, item: _FSItem, reply: ((attributes: _FSItemAttributes, error: _NSError) => void) | null): void;
+    getAttributes$ofItem$replyHandler$(desiredAttributes: _FSItemGetAttributesRequest, item: _FSItem, reply: ((attributes: _FSItemAttributes, error: _NSError) => void) | null): void;
     /**
      * Sets the given attributes on an item. Several attributes are considered "read-only", and an attempt to set these attributes results in an error with the code `EINVAL`. A request may set ``FSItem/Attributes/size`` beyond the end of the file. If the underlying file system doesn't support sparse files, allocate space to fill the new file size. Either fill this space with zeroes, or configure it to read as zeroes. If a request sets the file size below the current end-of-file, truncate the file and return any unused space to the file system as free space. Ignore attempts to set the size of directories or symbolic links; don't produce an error. If the caller attepts to sest an attribute not supported by the on-disk file system format, don't produce an error. The upper layers of the framework will detect this situation. - Parameters: - newAttributes: A request containing the attributes to set. - item: The item on which to set the attributes. - reply: A block or closure to indicate success or failure. If setting attributes succeeds, pass an ``FSItemAttributes`` with the item's updated attributes and a `nil` error. If setting attributes fails, pass the relevant error as the second parameter; FSKit ignores any ``FSItemAttributes`` in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSItemAttributes`` or throw an error.
      */
-    setAttributes$onItem$replyHandler$?(newAttributes: _FSItemSetAttributesRequest, item: _FSItem, reply: ((attributes: _FSItemAttributes, error: _NSError) => void) | null): void;
+    setAttributes$onItem$replyHandler$(newAttributes: _FSItemSetAttributesRequest, item: _FSItem, reply: ((attributes: _FSItemAttributes, error: _NSError) => void) | null): void;
     /**
      * Looks up an item within a directory. If no item matching `name` exists in the directory indicated by `directory`, complete the request with an error with a domain of <doc://com.apple.documentation/documentation/Foundation/NSPOSIXErrorDomain> and a code of `ENOENT`. > Tip: The ``FSFileName`` sent back to the caller may differ from the `name` parameter. This flexibility allows your implementation to handle case-insensitive and case-sensitive file systems. It might also be the case that `name` uses a composed Unicode string, but the name maintained by the file system and provided to the caller is uncomposed Unicode. - Parameters: - name: The name of the item to look up. - directory: The directory in which to look up the item. - reply: A block or closure to indicate success or failure. If lookup succeeds, pass the found ``FSItem`` and its ``FSFileName`` (as saved within the file system), along with a `nil` error. If lookup fails, pass the relevant error as the third parameter; any ``FSItem`` or ``FSFileName`` are ignored in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSItem`` and ``FSFileName`` as a tuple or throw an error.
      */
-    lookupItemNamed$inDirectory$replyHandler$?(name: _FSFileName, directory: _FSItem, reply: ((theItem: _FSItem, itemName: _FSFileName, error: _NSError) => void) | null): void;
+    lookupItemNamed$inDirectory$replyHandler$(name: _FSFileName, directory: _FSItem, reply: ((theItem: _FSItem, itemName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Reclaims an item, releasing any resources allocated for the item. FSKit guarantees that for every ``FSItem`` returned by the volume, a corresponding reclaim operation occurs after the upper layers no longer reference that item. > Note: Block device file systems may assess whether an underyling resource terminates before processing reclaim operations. On unary file systems, for example, the associated volumes unmount when such resources disconnect from the system. The unmount triggers a reclaiming of all items. Some implementations benefit greatly from short-circuiting in such cases. With a terminated resource, all I/O results in an error, making short-circuiting the most efficient response. - Parameters: - item: The item to reclaim. - reply: A block or closure to indicate success or failure. If removal fails, pass an error as the one parameter to the reply handler. If removal succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    reclaimItem$replyHandler$?(item: _FSItem, reply: ((error: _NSError) => void) | null): void;
+    reclaimItem$replyHandler$(item: _FSItem, reply: ((error: _NSError) => void) | null): void;
     /**
      * Reads a symbolic link. - Parameters: - item: The symbolic link to read from. FSKit guarantees this item is of type ``FSItem/ItemType/symlink``. - reply: A block or closure to indicate success or failure. If reading succeeds, pass the link's contents as an ``FSFileName`` and a `nil` error. If reading fails, pass the relevant error as the second parameter; FSKit ignores any ``FSFileName`` in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSFileName`` or throw an error.
      */
-    readSymbolicLink$replyHandler$?(item: _FSItem, reply: ((contents: _FSFileName, error: _NSError) => void) | null): void;
+    readSymbolicLink$replyHandler$(item: _FSItem, reply: ((contents: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Creates a new file or directory item. If an item named `name` already exists in the directory indicated by `directory`, complete the request with an error with a domain of <doc://com.apple.documentation/documentation/Foundation/NSPOSIXErrorDomain> and a code of `EEXIST`. - Parameters: - name: The new item's name. - type: The new item's type. Valid values are ``FSItem/ItemType/file`` or ``FSItem/ItemType/directory``. - directory: The directory in which to create the item. - newAttributes: Attributes to apply to the new item. - reply: A block or closure to indicate success or failure. If creation succeeds, pass the newly-created ``FSItem`` and its ``FSFileName``, along with a `nil` error. If creation fails, pass the relevant error as the third parameter; FSKit ignores any ``FSItem`` or ``FSFileName`` in this case. For an `async` Swift implementation, there's no reply handler; simply return a tuple of the ``FSItem`` and its ``FSFileName`` or throw an error.
      */
-    createItemNamed$type$inDirectory$attributes$replyHandler$?(name: _FSFileName, type: FSItemType, directory: _FSItem, newAttributes: _FSItemSetAttributesRequest, reply: ((newItem: _FSItem, newItemName: _FSFileName, error: _NSError) => void) | null): void;
+    createItemNamed$type$inDirectory$attributes$replyHandler$(name: _FSFileName, type: FSItemType, directory: _FSItem, newAttributes: _FSItemSetAttributesRequest, reply: ((newItem: _FSItem, newItemName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Creates a new symbolic link. If an item named `name` already exists in the directory indicated by `directory`, complete the request with an error with a domain of <doc://com.apple.documentation/documentation/Foundation/NSPOSIXErrorDomain> and a code of `EEXIST`. - Parameters: - name: The new item's name. - directory: The directory in which to create the item. - newAttributes: Attributes to apply to the new item. - contents: The contents of the new symbolic link. - reply: A block or closure to indicate success or failure. If creation succeeds, pass the newly-created ``FSItem`` and a `nil` error. If creation fails, pass the relevant error as the second parameter; FSKit ignores any ``FSItem`` in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSItem`` or throw an error.
      */
-    createSymbolicLinkNamed$inDirectory$attributes$linkContents$replyHandler$?(name: _FSFileName, directory: _FSItem, newAttributes: _FSItemSetAttributesRequest, contents: _FSFileName, reply: ((newItem: _FSItem, newItemName: _FSFileName, error: _NSError) => void) | null): void;
+    createSymbolicLinkNamed$inDirectory$attributes$linkContents$replyHandler$(name: _FSFileName, directory: _FSItem, newAttributes: _FSItemSetAttributesRequest, contents: _FSFileName, reply: ((newItem: _FSItem, newItemName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Creates a new hard link. If creating the link fails, complete the request with an error with a domain of <doc://com.apple.documentation/documentation/Foundation/NSPOSIXErrorDomain> and the following error codes: * `EEXIST` if there's already an item named `name` in the directory. * `EMLINK` if creating the link would exceed the maximum number of hard links supported on `item`. * `ENOTSUP` if the file system doesn't support creating hard links to the type of file system object that `item` represents. - Parameters: - item: The existing item to which to link. - name: The name for the new link. - directory: The directory in which to create the link. - reply: A block or closure to indicate success or failure. If creation succeeds, pass an ``FSFileName`` of the newly-created link and a `nil` error. If creation fails, pass the relevant error as the second parameter; FSKit ignores any ``FSFileName`` in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSFileName`` or throw an error.
      */
-    createLinkToItem$named$inDirectory$replyHandler$?(item: _FSItem, name: _FSFileName, directory: _FSItem, reply: ((linkName: _FSFileName, error: _NSError) => void) | null): void;
+    createLinkToItem$named$inDirectory$replyHandler$(item: _FSItem, name: _FSFileName, directory: _FSItem, reply: ((linkName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Removes an existing item from a given directory. Don't actually remove the item object itself in your implementation; instead, only remove the given item name from the given directory. Remove and deallocate the item in ``reclaimItem(_:replyHandler:)``. - Parameters: - item: The item to remove. - name: The name of the item to remove. - directory: The directory from which to remove the item. - reply: A block or closure to indicate success or failure. If removal fails, pass an error as the one parameter to the reply handler. If removal succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    removeItem$named$fromDirectory$replyHandler$?(item: _FSItem, name: _FSFileName, directory: _FSItem, reply: ((error: _NSError) => void) | null): void;
+    removeItem$named$fromDirectory$replyHandler$(item: _FSItem, name: _FSFileName, directory: _FSItem, reply: ((error: _NSError) => void) | null): void;
     /**
      * Renames an item from one path in the file system to another. Implement renaming along the lines of this algorithm: - If `item` is a file: - If the destination file exists: - Remove the destination file. - If the source and destination directories are the same: - Rewrite the name in the existing directory. - Else: - Write the new entry in the destination directory. - Clear the old directory entry. - If `item` is a directory: - If the destination directory exists: - If the destination directory isn't empty: - Fail the operation with an error of <doc://com.apple.documentation/documentation/Foundation/NSPOSIXErrorDomain> and a code of `ENOTEMPTY`. - Else: - Remove the destination directory. - If the source and destination directories are the same: - Rewrite the name in the existing directory. - Else: - If the destination is a child of the source directory: - Fail the operation with an error. - Else: - Write the new entry in the destination directory. - Update `"."` and `".."` in the moved directory. - Clear the old directory entry. - Parameters: - item: The file system object being renamed. - sourceDirectory: The directory that currently contains the item to rename. - sourceName: The name of the item within the source directory. - destinationName: The new name of the item as it appears in `destinationDirectory`. - destinationDirectory: The directory to contain the renamed object, which may be the same as `sourceDirectory`. - overItem: The file system object if the destination exists, as discovered in a prior lookup. If this parameter is non-`nil`, mark `overItem` as deleted, so the file system can free its allocated space on the next call to ``reclaimItem(_:replyHandler:)``. After doing so, ensure the operation finishes without errors. - reply: A block or closure to indicate success or failure. If renaming succeeds, pass the ``FSFileName`` as it exists within `destinationDirectory` and a `nil` error. If renaming fails, pass the relevant error as the second parameter; FSKit ignores any ``FSFileName`` in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSFileName`` or throw an error.
      */
-    renameItem$inDirectory$named$toNewName$inDirectory$overItem$replyHandler$?(item: _FSItem, sourceDirectory: _FSItem, sourceName: _FSFileName, destinationName: _FSFileName, destinationDirectory: _FSItem, overItem: _FSItem | null, reply: ((newName: _FSFileName, error: _NSError) => void) | null): void;
+    renameItem$inDirectory$named$toNewName$inDirectory$overItem$replyHandler$(item: _FSItem, sourceDirectory: _FSItem, sourceName: _FSFileName, destinationName: _FSFileName, destinationDirectory: _FSItem, overItem: _FSItem | null, reply: ((newName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * Enumerates the contents of the given directory. This method uses the ``FSDirectoryEntryPacker/packEntry(name:itemType:itemID:nextCookie:attributes:)`` method of the `packer` parameter to deliver the enumerated items to the caller. The general flow of an enumeration implementation follows these steps: 1. Enumeration starts with a call to `enumerateDirectory` using the initial next-cookie and verifier values ``FSDirectoryCookieInitial`` and ``FSDirectoryVerifierInitial``, respectively. 2. The implementation uses `packer` to pack the initial set of directory entries. Packing also sets a `nextCookie` to use on the next call. 3. The implementation replies with a new verifier value, a nonzero value that reflects the directory's current version. 4. On the next call the implementation packs the next set of entries, starting with the item indicated by `cookie`. If `cookie` doesn't resolve to a valid directory entry, complete the request with an error of domain <doc://com.apple.documentation/documentation/Foundation/NSPOSIXErrorDomain> and code ``FSError/Code/invalidDirectoryCookie``. When packing, make sure to use acceptable directory entry names and unambiguous input to all file operations that take names without additional normalization, such as`lookupName`. > Tip: If the `attributes` parameter is `nil`, include at least two entries in a directory: `"."` and `".."`, which represent the current and parent directories, respectively. Both of these items have type ``FSItem/ItemType/directory``. For the root directory, `"."` and `".."` have identical contents. Don't pack `"."` and `".."` if `attributes` isn't `nil`. - Parameters: - directory: The item to enumerate. FSKit guarantees this item is of type ``FSItem/ItemType/directory``. - cookie: A value that indicates the location within the directory from which to enumerate. Your implementation defines the semantics of the cookie values; they're opaque to FSKit. The first call to the enumerate method passes ``FSDirectoryCookieInitial`` for this parameter. Subsequent calls pass whatever cookie value you previously passed to the packer's `nextCookie` parmeter. - verifier: A tool to detect whether the directory contents changed since the last call to `enumerateDirectory`. Your implementation defines the semantics of the verifier values; they're opaque to FSKit. The first call to the enumerate method passes ``FSDirectoryVerifierInitial`` for this parameter. Subsequent calls pass whatever cookie value you previously passed to the packer's `currentVerifier` parmeter. - attributes: The desired attributes to provide, or `nil` if the caller doesn't require attributes. - packer: An object that your implementation uses to enumerate directory items, packing one item per callback to `enumerateDirectory`. - reply: A block or closure to indicate success or failure. If enumeration succeeds, pass the current verifier and a `nil` error. If enumeration fails, pass the relevant error as the second parameter; FSKit ignores any verifier in this case. For an `async` Swift implementation, there's no reply handler; simply return the current verifier or throw an error.
      */
-    enumerateDirectory$startingAtCookie$verifier$providingAttributes$usingPacker$replyHandler$?(directory: _FSItem, cookie: number, verifier: number, attributes: _FSItemGetAttributesRequest | null, packer: _FSDirectoryEntryPacker, reply: ((currentVerifier: number, error: _NSError) => void) | null): void;
+    enumerateDirectory$startingAtCookie$verifier$providingAttributes$usingPacker$replyHandler$(directory: _FSItem, cookie: number, verifier: number, attributes: _FSItemGetAttributesRequest | null, packer: _FSDirectoryEntryPacker, reply: ((currentVerifier: number, error: _NSError) => void) | null): void;
     /**
      * Activates the volume using the specified options. When FSKit calls this method, allocate any in-memory state required to represent the file system. Also allocate an ``FSItem`` for the root directory of the file system, and pass it to the reply block. FSKit caches this root item for the lifetime of the volume, and uses it as a starting point for all file look-ups. Volume activation occurs prior to any call to mount the volume. - Parameters: - options: Options to apply to the activation. These can include security-scoped file paths. There are no defined options currently. - reply: A block or closure to indicate success or failure. If activation succeeds, pass the root ``FSItem`` and a `nil` error. If activation fails, pass the relevant error as the second parameter; FSKit ignores any ``FSItem`` in this case. In Swift, `reply` takes only the ``FSItem`` as the parameter; you signal any error with a `throw`. For an `async` Swift implementation, there's no reply handler; simply return the ``FSItem`` or throw an error.
      */
-    activateWithOptions$replyHandler$?(options: _FSTaskOptions, reply: ((rootItem: _FSItem, err: _NSError) => void) | null): void;
+    activateWithOptions$replyHandler$(options: _FSTaskOptions, reply: ((rootItem: _FSItem, err: _NSError) => void) | null): void;
     /**
      * Tears down a previously initialized volume instance. Set up your implementation to release any resources allocated for the volume instance. By the time you receive this callback, FSKit has already performed a reclaim call to release all other file nodes associated with this file system instance. Avoid performing any I/O in this method. Prior to calling this method, FSKit has already issued a sync call to perform any cleanup-related I/O. FSKit unmounts any mounted volume with a call to ``unmount(replyHandler:)`` prior to the deactivate callback. - Parameters: - options: Options to apply to the deactivation. - reply: A block or closure to indicate success or failure. If activation fails, pass an error as the one parameter to the reply handler. If activation succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    deactivateWithOptions$replyHandler$?(options: FSDeactivateOptions, reply: ((err: _NSError) => void) | null): void;
+    deactivateWithOptions$replyHandler$(options: FSDeactivateOptions, reply: ((err: _NSError) => void) | null): void;
     /** A property that provides the supported capabilities of the volume. */
-    supportedVolumeCapabilities?(): _FSVolumeSupportedCapabilities;
+    supportedVolumeCapabilities(): _FSVolumeSupportedCapabilities;
     /** A property that provides up-to-date statistics of the volume. */
-    volumeStatistics?(): _FSStatFSResult;
+    volumeStatistics(): _FSStatFSResult;
     /**
      * A property that allows the file system to use open-unlink emulation. _Open-unlink_ functionality refers to a file system's ability to support an open file being fully unlinked from the file system namespace. If a file system doesn't support this functionality, FSKit can emulate it instead; this is called "open-unlink emulation". Implement this property to return `true` (Swift) or `YES` (Objective-C) to allow FSKit to perform open-unlink emulation. If you don't implement this property at all, FSKit doesn't perform open-unlink emulation for this volume. FSKit reads this value after the file system replies to the `loadResource` message. Changing the returned value during the runtime of the volume has no effect.
      */

package/dist/FSKit/FSVolumePathConfOperations.d.ts

@@ -1,16 +1,16 @@
 export interface _FSVolumePathConfOperations {
     /** A property that represents the maximum number of hard links to the object. */
-    maximumLinkCount?(): number;
+    maximumLinkCount(): number;
     /** A property that represents the maximum length of a component of a filename. */
-    maximumNameLength?(): number;
+    maximumNameLength(): number;
     /**
      * A Boolean property that indicates whether the volume restricts ownership changes based on authorization. If this value is true, the volume rejects a `chown(2)` from anyone other than the superuser.
      */
-    restrictsOwnershipChanges?(): boolean;
+    restrictsOwnershipChanges(): boolean;
     /**
      * A property that indicates whether the volume truncates files longer than its maximum supported length. If this value is `true`, the volume truncates the filename to ``maximumNameLength`` if the filename is longer than that. If this value is false, the file system responds with the error code `ENAMETOOLONG` if the filename is longer than ``maximumNameLength``.
      */
-    truncatesLongNames?(): boolean;
+    truncatesLongNames(): boolean;
     /**
      * The maximum extended attribute size in bytes. Implement at least one of `maximumXattrSize` or ``maximumXattrSizeInBits``. FSKit automatically converts from one to another if needed. If you implement both, FSKit uses only the `maximumXattrSizeInBits` implementation.
      */

package/dist/FSKit/FSVolumePreallocateOperations.d.ts

@@ -6,7 +6,7 @@ export interface _FSVolumePreallocateOperations {
     /**
      * Prealocates disk space for the given item. - Parameters: - item: The item for which to preallocate space. - offset: The offset from which to allocate. - length: The length of the space in bytes. - flags: Flags that affect the preallocation behavior. - reply: A block or closure to indicate success or failure. If preallocation succeeds, pass the amount of bytes allocated and a `nil` error. If preallocation fails, pass the relevant error as the second parameter; FSKit ignores any byte count in this case. For an `async` Swift implementation, there's no reply handler; simply return the allocated byte count or throw an error.
      */
-    preallocateSpaceForItem$atOffset$length$flags$replyHandler$?(item: _FSItem, offset: NobjcObject, length: number, flags: FSPreallocateFlags, reply: ((bytesAllocated: number, error: _NSError) => void) | null): void;
+    preallocateSpaceForItem$atOffset$length$flags$replyHandler$(item: _FSItem, offset: NobjcObject, length: number, flags: FSPreallocateFlags, reply: ((bytesAllocated: number, error: _NSError) => void) | null): void;
     /**
      * A Boolean value that instructs FSKit not to call this protocol's methods, even if the volume conforms to it. FSKit reads this value after the file system replies to the `loadResource` message. Changing the returned value during the runtime of the volume has no effect.
      */

package/dist/FSKit/FSVolumeReadWriteOperations.d.ts

@@ -7,9 +7,9 @@ export interface _FSVolumeReadWriteOperations {
     /**
      * Reads the contents of the given file item. If the number of bytes requested exceeds the number of bytes available before the end of the file, then the call copies only those bytes to `buffer`. If `offset` points past the last valid byte of the file, don't reply with an error but set `actuallyRead` to `0`. - Parameters: - item: The item from which to read. FSKit guarantees this item will be of type ``FSItem/ItemType/file``. - offset: The offset in the file from which to start reading. - length: The number of bytes to read. - buffer: A buffer to receive the bytes read from the file. - reply: A block or closure to indicate success or failure. If reading succeeds, pass the number of bytes read and a `nil` error. If reading fails, pass the number of bytes read prior to the error along with the relevant error. For an `async` Swift implementation, there's no reply handler; simply return the byte count or throw an error.
      */
-    readFromFile$offset$length$intoBuffer$replyHandler$?(item: _FSItem, offset: NobjcObject, length: number, buffer: _FSMutableFileDataBuffer, reply: ((actuallyRead: number, error: _NSError) => void) | null): void;
+    readFromFile$offset$length$intoBuffer$replyHandler$(item: _FSItem, offset: NobjcObject, length: number, buffer: _FSMutableFileDataBuffer, reply: ((actuallyRead: number, error: _NSError) => void) | null): void;
     /**
      * Writes contents to the given file item. FSKit expects this routine to allocate space in the file system to extend the file as necessary. If the volume experiences an out-of-space condition, reply with an error of domain <doc://com.apple.documentation/documentation/Foundation/NSPOSIXErrorDomain> and code `ENOSPC`. - Parameters: - contents: A buffer containing the data to write to the file. - item: The item to which to write. FSKit guarantees this item will be of type ``FSItem/ItemType/file``. - offset: The offset in the file from which to start writing. - reply: A block or closure to indicate success or failure. If writing succeeds, pass the number of bytes written and a `nil` error. If writing fails, pass the number of bytes written prior to the error along with the relevant error. For an `async` Swift implementation, there's no reply handler; simply return the byte count or throw an error.
      */
-    writeContents$toFile$atOffset$replyHandler$?(contents: _NSData, item: _FSItem, offset: NobjcObject, reply: ((actuallyWritten: number, error: _NSError) => void) | null): void;
+    writeContents$toFile$atOffset$replyHandler$(contents: _NSData, item: _FSItem, offset: NobjcObject, reply: ((actuallyWritten: number, error: _NSError) => void) | null): void;
 }

package/dist/FSKit/FSVolumeRenameOperations.d.ts

@@ -4,7 +4,7 @@ export interface _FSVolumeRenameOperations {
     /**
      * Sets a new name for the volume. - Parameters: - name: The new volume name. - reply: A block or closure to indicate success or failure. If renaming succeeds, pass an ``FSFileName`` of the new volume name and a `nil` error. If renaming fails, pass the relevant error as the second parameter; FSKit ignores any ``FSFileName`` in this case. For an `async` Swift implementation, there's no reply handler; simply return the ``FSFileName`` or throw an error.
      */
-    setVolumeName$replyHandler$?(name: _FSFileName, reply: ((newName: _FSFileName, error: _NSError) => void) | null): void;
+    setVolumeName$replyHandler$(name: _FSFileName, reply: ((newName: _FSFileName, error: _NSError) => void) | null): void;
     /**
      * A Boolean value that instructs FSKit not to call this protocol's methods, even if the volume conforms to it. FSKit reads this value after the file system replies to the `loadResource` message. Changing the returned value during the runtime of the volume has no effect.
      */

package/dist/FSKit/FSVolumeXattrOperations.d.ts

@@ -12,15 +12,15 @@ export interface _FSVolumeXattrOperations {
     /**
      * Gets the specified extended attribute of the given item. - Parameters: - name: The extended attribute name. - item: The item for which to get the extended attribute. - reply: A block or closure to indicate success or failure. If getting the attribute succeeds, pass an data instance containing the extended attribute data and a `nil` error. If getting the attribute fails, pass the relevant error as the second parameter; FSKit ignores any data in this case. For an `async` Swift implementation, there's no reply handler; simply return the data or throw an error.
      */
-    getXattrNamed$ofItem$replyHandler$?(name: _FSFileName, item: _FSItem, reply: ((value: _NSData, error: _NSError) => void) | null): void;
+    getXattrNamed$ofItem$replyHandler$(name: _FSFileName, item: _FSItem, reply: ((value: _NSData, error: _NSError) => void) | null): void;
     /**
      * Sets the specified extended attribute data on the given item. - Parameters: - name: The extended attribute name. - value: The extended attribute value to set. This can't be `nil`, unless the policy is ``FSVolume/SetXattrPolicy/delete``. - item: The item on which to set the extended attribute. - policy: The policy to apply when setting the attribute. See ``FSSetXattrPolicy`` for possible values. - reply: A block or closure to indicate success or failure. If setting the attribute fails, pass an error as the one parameter to the reply handler. If setting the attribute succeeds, pass `nil`. For an `async` Swift implementation, there's no reply handler; simply throw an error or return normally.
      */
-    setXattrNamed$toData$onItem$policy$replyHandler$?(name: _FSFileName, value: _NSData | null, item: _FSItem, policy: FSSetXattrPolicy, reply: ((error: _NSError) => void) | null): void;
+    setXattrNamed$toData$onItem$policy$replyHandler$(name: _FSFileName, value: _NSData | null, item: _FSItem, policy: FSSetXattrPolicy, reply: ((error: _NSError) => void) | null): void;
     /**
      * Gets the list of extended attributes currently set on the given item. - Parameters: - item: The item from which to get extended attributes. - reply: A block or closure to indicate success or failure. If getting the list of extended attributes succeeds, pass the xattrs as an array of ``FSFileName`` instances and a `nil` error. If getting the attriubtes fails, pass `nil` along with the relevant error. For an `async` Swift implementation, there's no reply handler; simply return the byte count or throw an error.
      */
-    listXattrsOfItem$replyHandler$?(item: _FSItem, reply: ((value: _NSArray, error: _NSError) => void) | null): void;
+    listXattrsOfItem$replyHandler$(item: _FSItem, reply: ((value: _NSArray, error: _NSError) => void) | null): void;
     /**
      * A Boolean value that instructs FSKit not to call this protocol's methods, even if the volume conforms to it. FSKit reads this value after the file system replies to the `loadResource` message. Changing the returned value during the runtime of the volume has no effect.
      */

package/dist/FileProvider/NSFileProviderChangeObserver.d.ts

@@ -3,17 +3,17 @@ import type { _NSData } from "../Foundation/NSData.js";
 import type { _NSError } from "../Foundation/NSError.js";
 export interface _NSFileProviderChangeObserver {
     /** Send updates to existing items, or insert new items. */
-    didUpdateItems$?(updatedItems: _NSArray): void;
+    didUpdateItems$(updatedItems: _NSArray): void;
     /** Delete existing items. No-op if the item was unknown. */
-    didDeleteItemsWithIdentifiers$?(deletedItemIdentifiers: _NSArray): void;
+    didDeleteItemsWithIdentifiers$(deletedItemIdentifiers: _NSArray): void;
     /**
      * This method is used to complete a batch of changes. Follow the advice in -[NSFileProviderChangeObserver suggestedBatchSize] to determine when to call this method. It is expected that the sync anchor passed here be different than the sync anchor that the enumeration started at, unless the client was already up to date on all the changes on the server, and didn't have any pending updates or deletions. Additionally, if the client is up to date on all the changes on the server it should set moreComing to NO. Sync anchor data is limited to 500 bytes. Setting a larger anchor has the same effect as calling finishEnumeratingWithError with an expired sync anchor error.
      */
-    finishEnumeratingChangesUpToSyncAnchor$moreComing$?(anchor: _NSData, moreComing: boolean): void;
+    finishEnumeratingChangesUpToSyncAnchor$moreComing$(anchor: _NSData, moreComing: boolean): void;
     /**
      * If the enumeration fails with NSFileProviderErrorSyncAnchorExpired, we will drop all cached data and start the enumeration over starting with sync anchor nil.
      */
-    finishEnumeratingWithError$?(error: _NSError): void;
+    finishEnumeratingWithError$(error: _NSError): void;
     /**
      * Size of the batch 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 changes on a container in various cases (container presenter in the UI, file opened in an application, ...). Each case has its own performance profile. In case the enumerator has already more than suggestedBatchSize pending changes ready to enumerate, it is suggested it split the list of changes into several batches. If the enumerator does not have suggestedBatchSize ready to enumerator, the enumerator should finish immediately and not wait for more incoming changes to enumerate. By taking into account the suggested size, the enumeration will guarantee the best user experience possible. Large batches can cause performance issues. And when the device reboots, enumerations will resume from the latest known sync anchor. Telling the system about the latest sync anchor more frequently will reduce the number of re-enumerations on system reboot. The system enforces a maximum of 100 times the suggested size.
      */

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/NSFileProviderDomainIdentifier.d.ts

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

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/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/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/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;
 }