objc2_file_provider/generated/
NSFileProviderReplicatedExtension.rs

1//! This file has been automatically generated by `objc2`'s `header-translator`.
2//! DO NOT EDIT
3use core::ffi::*;
4use core::ptr::NonNull;
5use objc2::__framework_prelude::*;
6#[cfg(feature = "objc2-core-foundation")]
7use objc2_core_foundation::*;
8use objc2_foundation::*;
9
10use crate::*;
11
12/// Options passed on item creation.
13///
14/// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileprovidercreateitemoptions?language=objc)
15// NS_OPTIONS
16#[repr(transparent)]
17#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)]
18pub struct NSFileProviderCreateItemOptions(pub NSUInteger);
19bitflags::bitflags! {
20    impl NSFileProviderCreateItemOptions: NSUInteger {
21/// The imported item may already exist.
22///
23/// This can happen because:
24///
25/// 1. The imported item was found on disk after the synchronisation state was
26/// lost, for example following the restoration of a backup, or the migration
27/// to a new device.
28///
29/// 2. Two directories are merged together, due to the extension returning
30/// the same itemIdentifier for both directories on the createItem completion handler.
31/// Each child resulting of the merge may be recreated with the
32/// mayAlreadyExist option. This allows the extension to recursively merge
33/// directories.
34///
35/// The Extension should assess whether the item could actually be a disk
36/// representation of an already existing item.
37///
38/// The best user experience is to match the requested item to one on the server,
39/// if the extension is able to confirm that the disk item is representing an item already on
40/// the server.
41///
42/// Given that this flag may be set when the system is reimporting all items from disk,
43/// it is advised that the Extension attempts assessment methods for each item
44/// in order from cheapest to most expensive (in terms of CPU and network), in order
45/// to avoid unnecessary work.
46///
47/// When all the items pending reimport have been processed, the system
48/// will call -[NSFileProviderExtension importDidFinishWithCompletionHandler:].
49        #[doc(alias = "NSFileProviderCreateItemMayAlreadyExist")]
50        const MayAlreadyExist = 1<<0;
51/// This item is recreated after the system failed to apply a deletion requested
52/// by the extension because the item was found to be edited locally.
53/// This happens only if the edit wasn't yet known by the system at the time the
54/// deletion was requested.
55        #[doc(alias = "NSFileProviderCreateItemDeletionConflicted")]
56        const DeletionConflicted = 1<<1;
57    }
58}
59
60unsafe impl Encode for NSFileProviderCreateItemOptions {
61    const ENCODING: Encoding = NSUInteger::ENCODING;
62}
63
64unsafe impl RefEncode for NSFileProviderCreateItemOptions {
65    const ENCODING_REF: Encoding = Encoding::Pointer(&Self::ENCODING);
66}
67
68/// Options passed on item deletion.
69///
70/// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderdeleteitemoptions?language=objc)
71// NS_OPTIONS
72#[repr(transparent)]
73#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)]
74pub struct NSFileProviderDeleteItemOptions(pub NSUInteger);
75bitflags::bitflags! {
76    impl NSFileProviderDeleteItemOptions: NSUInteger {
77/// The deletion of the item is recursive.
78        #[doc(alias = "NSFileProviderDeleteItemRecursive")]
79        const Recursive = 1<<0;
80    }
81}
82
83unsafe impl Encode for NSFileProviderDeleteItemOptions {
84    const ENCODING: Encoding = NSUInteger::ENCODING;
85}
86
87unsafe impl RefEncode for NSFileProviderDeleteItemOptions {
88    const ENCODING_REF: Encoding = Encoding::Pointer(&Self::ENCODING);
89}
90
91/// NSFileProviderMaterializationFlags are used to inform the system about specific conditions
92/// that apply to the content retrieved by the provider in fetchPartialContentsForItemWithIdentifier.
93///
94/// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileprovidermaterializationflags?language=objc)
95// NS_OPTIONS
96#[repr(transparent)]
97#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)]
98pub struct NSFileProviderMaterializationFlags(pub NSUInteger);
99bitflags::bitflags! {
100    impl NSFileProviderMaterializationFlags: NSUInteger {
101/// By default, the system will track which parts of the returned file are sparse; those parts will remain non-materialized
102/// and trigger subsequent calls to the materialization methods on access. Returning this flag will instead cause the entire
103/// file to be marked as materialized. This is useful if the resulting file is known to contain sparse parts,
104/// and all the remaining parts have been filled in.
105/// This flag is ignored if the provided range doesn't cover the entire file (ie. [0, EOF]).
106/// This flag is not functional prior to macOS 13.3.
107        #[doc(alias = "NSFileProviderMaterializationFlagsKnownSparseRanges")]
108        const KnownSparseRanges = 1<<0;
109    }
110}
111
112unsafe impl Encode for NSFileProviderMaterializationFlags {
113    const ENCODING: Encoding = NSUInteger::ENCODING;
114}
115
116unsafe impl RefEncode for NSFileProviderMaterializationFlags {
117    const ENCODING_REF: Encoding = Encoding::Pointer(&Self::ENCODING);
118}
119
120/// Used by the system to express options and constraints to the provider in fetchPartialContentsForItemWithIdentifier.
121///
122/// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderfetchcontentsoptions?language=objc)
123// NS_OPTIONS
124#[repr(transparent)]
125#[derive(Clone, Copy, Debug, PartialEq, Eq, Hash, PartialOrd, Ord)]
126pub struct NSFileProviderFetchContentsOptions(pub NSUInteger);
127bitflags::bitflags! {
128    impl NSFileProviderFetchContentsOptions: NSUInteger {
129/// Set by the system to inform the provider that any other content version than the requested one
130/// will be discarded.
131/// If the provider cannot supply this version, it should fail with NSFileProviderErrorVersionNoLongerAvailable.
132        #[doc(alias = "NSFileProviderFetchContentsOptionsStrictVersioning")]
133        const StrictVersioning = 1<<0;
134    }
135}
136
137unsafe impl Encode for NSFileProviderFetchContentsOptions {
138    const ENCODING: Encoding = NSUInteger::ENCODING;
139}
140
141unsafe impl RefEncode for NSFileProviderFetchContentsOptions {
142    const ENCODING_REF: Encoding = Encoding::Pointer(&Self::ENCODING);
143}
144
145extern_protocol!(
146    /// [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderenumerating?language=objc)
147    pub unsafe trait NSFileProviderEnumerating: NSObjectProtocol {
148        #[cfg(all(
149            feature = "NSFileProviderEnumerating",
150            feature = "NSFileProviderItem",
151            feature = "NSFileProviderRequest"
152        ))]
153        /// Create an enumerator for an item.
154        ///
155        /// This method is called when the user lists the content of folder it never accessed
156        /// before. This can happen either when using Finder or when listing the content of
157        /// the directory from a Terminal (for instance using the `ls` command line tool). The
158        /// system will use the enumerator to list the children of the directory by calling
159        /// -[NSFileProviderEnumerator enumerateItemsForObserver:startingAtPage:] until nil
160        /// is passed to -[NSFileProviderEnumerationObserver finishEnumeratingUpToPage:].
161        /// Once this has been called, the directory and its children should be included in the
162        /// working set.
163        ///
164        /// This is also used to subscribe to live updates for a single document.
165        ///
166        /// The system will keep an enumerator open in the extension on directories that are
167        /// presented to the user (for instance, in Finder), and on document on which an application
168        /// has a NSFilePresenter. The provider can use the existence of that enumerator as a hint
169        /// that the user is actively seeing / using the item in question, and prioritize the delivery
170        /// of updates on the item or its children in the working set.
171        ///
172        /// If returning nil, you must set the error out parameter.
173        ///
174        /// Working set enumerator:
175        /// -----------------------
176        /// The working set enumerator is a special enumerator (NSFileProviderWorkingSetContainerItemIdentifier)
177        /// the system uses to detect changes that should be synced to the disk and/or searchable
178        /// in Spotlight. Because that enumerator is by definition used for change detection, the
179        /// working set enumerator must implement
180        /// -[NSFileProviderEnumerator enumerateChangesForObserver:fromSyncAnchor:] and
181        /// -[NSFileProviderEnumerator currentSyncAnchorWithCompletionHandler:].
182        ///
183        /// The system guarantees that it has a single consumer for the working set. This means there
184        /// will never be two concurrent enumerations of the working set and will always do forward
185        /// progress: the system will only ask for changes from the last requested sync anchor or
186        /// the last returned sync anchor and the extension should be prepared for it.
187        ///
188        /// The expiration of the sync anchor of the working set will cause a very expensive scan
189        /// of all the items known by the system.
190        ///
191        /// The system ingests the changes from the working set and applies the changes to the
192        /// disk replicate and the spotlight index. Before ingesting the update for an item,
193        /// the system will check if the enumeration of the item races against a call to
194        /// createItemBasedOnTemplate, modifyItem, ... that may affect the item. If a potential race
195        /// is detected, the system will call itemForItemIdentifier in order to resolve the race.
196        ///
197        /// If the provider exposes the key NSExtensionFileProviderAppliesChangesAtomically with value
198        /// YES in its Info.plist, it is considered to apply the changes atomically, in which case the
199        /// system does not need to check for potential races.
200        ///
201        /// Execution time:
202        /// ---------------
203        /// The system expects this call to complete quickly, it should build the object that will be
204        /// used for enumeration and return it. The enumeration logic should happen when the system
205        /// calls `-[NSFileProviderEnumerator enumerateItemsForObserver:startingAtPage:]` or
206        /// `-[NSFileProviderEnumerator enumerateChangesForObserver:fromSyncAnchor:]`.
207        ///
208        /// Error cases:
209        /// ------------
210        /// If containerItemIdentifier is NSFileProviderTrashContainerItemIdentifier and
211        /// the extension does not support trashing items, then it should fail the call
212        /// with the NSFeatureUnsupportedError error code from the NSCocoaErrorDomain
213        /// domain.
214        ///
215        /// If the item requested containerItemIdentifier does not exist in the provider,
216        /// the extension should fail with NSFileProviderErrorNoSuchItem. In that case,
217        /// the system will consider the item has been deleted and attempt to delete the
218        /// item from disk.
219        ///
220        /// The extension can also report the NSFileProviderErrorNotAuthenticated,
221        /// NSFileProviderErrorServerUnreachable in case the item cannot be fetched
222        /// because of the current state of the system / domain. In that case, the
223        /// system will present an appropriate error message and back off until the
224        /// next time it is signalled.
225        ///
226        /// Any other error, including crashes of the extension process, will be considered to be transient
227        /// and will cause the enumeration to be retried.
228        ///
229        /// Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain.
230        ///
231        /// For errors which can not be represented using an existing error code in one of these domains, the extension
232        /// should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid.
233        /// The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not
234        /// be represented.
235        #[unsafe(method(enumeratorForContainerItemIdentifier:request:error:_))]
236        #[unsafe(method_family = none)]
237        unsafe fn enumeratorForContainerItemIdentifier_request_error(
238            &self,
239            container_item_identifier: &NSFileProviderItemIdentifier,
240            request: &NSFileProviderRequest,
241        ) -> Result<Retained<ProtocolObject<dyn NSFileProviderEnumerator>>, Retained<NSError>>;
242    }
243);
244
245extern_protocol!(
246    /// FileProvider extension for which the system replicates the content on disk.
247    ///
248    /// The extension exposes a hierarchy of NSFileProviderItem instances that the system
249    /// will replicate on disk as a file hierarchy. The file hierarchy reflects the filename,
250    /// parent, content, and metadata described by the NSFileProviderItem. In case two items
251    /// are at the same disk location (same parent and filename), the system may choose to
252    /// "bounce" an item.
253    ///
254    /// The system lazily replicates the item hierarchy: items are created "dataless" on disk
255    /// and the content (for files) or list of children (for folders) is fetched on first
256    /// access by calling fetchContentsForItemWithIdentifier, or enumeratorForContainerItemIdentifier.
257    ///
258    /// The provider can notify the system of changes on the items by publishing those on the
259    /// enumerator for the working set. The system notifies the extension of changes made by the
260    /// user on disk by calling createItemBasedOnTemplate, modifyItem, or deleteItemWithIdentifier.
261    ///
262    /// Concurrency:
263    /// ------------
264    /// A replicated extension class must be prepared to handle multiple concurrent calls since the
265    /// system may perform several concurrent operations (for instance, modifying an item, while enumerating
266    /// the working set, creating another item, and fetching the contents of yet another item).
267    ///
268    /// The system has limits to the number of concurrent operations.When the number of concurrent
269    /// operations is reached, the system will not schedule additional operations falling in that category
270    /// until at least one of the running operation has completed by calling its completion handler.
271    ///
272    /// The system currently separates the operations into the following categories:
273    /// - enumeration of the working set. At most 1 enumeration of the working set can happen at a given time
274    /// - downloads. The system has a per-domain limit on the number of concurrent calls to fetchContents and similar calls.
275    /// That limit is configurable by setting the NSExtensionFileProviderDownloadPipelineDepth key to an integer
276    /// value (between 1 and 128) in the Info.plist of the extension.
277    /// The configuration key is honored starting in macOS 11.0 and iOS 16.0.
278    /// - uploads. The system has a per-domain limit on the number of concurrent calls to createItemBasedOnTemplate and
279    /// modifyItem when the call includes new content to be uploaded.
280    /// That limit is configurable by setting the NSExtensionFileProviderUploadPipelineDepth key to an integer value
281    /// (between 1 and 128) in the Info.plist of the extension.
282    /// The configuration key is honored starting in macOS 12.0 and iOS 16.0.
283    /// - metadata-only uploads. The system has a per-domain limit on the number of concurrent calls to createItemBasedOnTemplate
284    /// and modifyItem when the call does not include new content to be uploaded.
285    /// That limit is configurable by setting the NSExtensionFileProviderMetadataOnlyUploadPipelineDepth key to an
286    /// integer value (between 1 and 128) in the Info.plist of the extension.
287    /// The configuration key is honored starting in macOS 15.0 and iOS 18.0.
288    ///
289    /// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderreplicatedextension?language=objc)
290    pub unsafe trait NSFileProviderReplicatedExtension:
291        NSObjectProtocol + NSFileProviderEnumerating
292    {
293        #[cfg(feature = "NSFileProviderDomain")]
294        /// Create a new instance of the replicated provider for the specified domain.
295        #[unsafe(method(initWithDomain:))]
296        #[unsafe(method_family = init)]
297        unsafe fn initWithDomain(
298            this: Allocated<Self>,
299            domain: &NSFileProviderDomain,
300        ) -> Retained<Self>;
301
302        /// Called before the instance is discarded.
303        ///
304        /// Several instances of a replicated provider can be hosted by the same process, either because
305        /// the user has several active domains, or because an instance got discarded and a new one
306        /// is created by the system. This method is called before an instance is discarded and should
307        /// make sure that all references to the instance are released so that the instance can be
308        /// deallocated.
309        #[unsafe(method(invalidate))]
310        #[unsafe(method_family = none)]
311        unsafe fn invalidate(&self);
312
313        #[cfg(all(
314            feature = "NSFileProviderItem",
315            feature = "NSFileProviderRequest",
316            feature = "block2"
317        ))]
318        /// Fetch the metadata for the item with the provider identifier.
319        ///
320        /// Error cases:
321        /// ------------
322        /// If the metadata lookup fails because the item is unknown, the call should
323        /// fail with the NSFileProviderErrorNoSuchItem error. In that case, the system
324        /// will consider the item has been removed from the domain and will attempt to
325        /// delete it from disk. In case that deletion fails because there are local
326        /// changes on this item, the system will re-create the item using createItemBasedOnTemplate.
327        ///
328        /// The extension can also report the NSFileProviderErrorNotAuthenticated,
329        /// NSFileProviderErrorServerUnreachable in case the item cannot be fetched
330        /// because of the current state of the system / domain. In that case, the
331        /// system will present an appropriate error message and back off until the
332        /// next time it is signalled.
333        ///
334        /// Any other error, including crashes of the extension process, will be considered to be
335        /// transient and will cause the lookup to be retried.
336        ///
337        /// Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain.
338        ///
339        /// For errors which can not be represented using an existing error code in one of these domains, the extension
340        /// should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid.
341        /// The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not
342        /// be represented.
343        ///
344        /// Cancellations:
345        /// ------------
346        /// If the NSProgress returned by this method is cancelled, the extension should
347        /// call the completion handler with (nil, NSUserCancelledError) in the NSProgress
348        /// cancellation handler.
349        ///
350        /// Execution time:
351        /// ---------------
352        /// This method is not expected to take more than a few seconds to complete the retrieval of the
353        /// metadata of the item. If the operation may not complete in a reasonable amount of time because,
354        /// for instance, of bad network conditions, it is recommended to report an error (for instance
355        /// NSFileProviderErrorServerUnreachable). The system will call `cancel` on the progress if the
356        /// operation takes too much time. The extension is then expected to quickly call the completion
357        /// handler.
358        #[unsafe(method(itemForIdentifier:request:completionHandler:))]
359        #[unsafe(method_family = none)]
360        unsafe fn itemForIdentifier_request_completionHandler(
361            &self,
362            identifier: &NSFileProviderItemIdentifier,
363            request: &NSFileProviderRequest,
364            completion_handler: &block2::DynBlock<dyn Fn(*mut NSFileProviderItem, *mut NSError)>,
365        ) -> Retained<NSProgress>;
366
367        #[cfg(all(
368            feature = "NSFileProviderItem",
369            feature = "NSFileProviderRequest",
370            feature = "block2"
371        ))]
372        /// Download the item for the given identifier and return it via the completion handler.
373        ///
374        /// The system learns of items through enumerations. Initially, this means that the
375        /// system is aware that an item (with a specific version) exists on the device.
376        ///
377        /// When the user accesses the item, the system makes a request for the contents of
378        /// the item. The provider can then fulfill the request by providing the item.
379        ///
380        /// The system takes ownership of the item and will move it out of the sandbox of
381        /// the provider.
382        ///
383        /// If the provider wishes to force materialization of a given item, the provider should use
384        /// `-[NSFileProviderManager requestDownloadForItemWithIdentifier:requestedRange:completionHandler:]`,
385        /// or configure the `-[NSFileProviderItem contentPolicy]`.
386        ///
387        /// The requestedVersion parameter specifies which version should be returned. A nil value
388        /// means that the latest known version should be returned. Except for the error case, the
389        /// version of the returned item is assumed to be identical to what was requested.
390        ///
391        /// requestedVersion is currently always set to nil.
392        ///
393        /// Concurrent Downloads:
394        /// ----------
395        /// The system will call fetchContents concurrently if there are multiple outstanding file download requests.
396        /// The provider can control the concurrency by setting the key NSExtensionFileProviderDownloadPipelineDepth
397        /// in the Info.plist of the extension to the number of concurrent downloads that the system should create
398        /// per domain. This number must be between 1 and 128, inclusive.
399        ///
400        /// File ownership:
401        /// ---------------
402        /// The retrieved content at `fileContents` URL must be a regular file on the same volume as the user-visible URL.
403        /// A suitable location can be retrieved using -[NSFileProviderManager temporaryDirectoryURLWithError:].
404        /// The system clones and unlinks the received fileContents. The extension should not mutate the corresponding
405        /// file after calling the completion handler. If the extension wishes to keep a copy of the content, it must
406        /// provide a clone of the that content as the URL passed to the completion handler.
407        ///
408        /// In case the extension or the system crashes between the moment the completion handler is called and the
409        /// moment the system unlinks the file, the file may unexpectedly still be on disk the next time an instance
410        /// of the extension is created. The extension is then responsible for deleting that file.
411        ///
412        /// Disallowing processes from fetching items:
413        /// ---------------
414        ///
415        /// The system automatically downloads files on POSIX accesses. The extension may wish to disallow this class of
416        /// downloads for specific applications.
417        ///
418        /// The extension can set an array of strings into the UserDefault key
419        /// "NSFileProviderExtensionNonMaterializingProcessNames". A process whose executable's filename on disk is an
420        /// exact match for an entry in this array will not be allowed to fetch items in the extension's domains. The comparison
421        /// is case sensitive.
422        ///
423        /// In macOS 11.0 and later, this list will be checked when a download is initiated through a POSIX filesystem call.
424        /// In macOS 11.4 and later, this list will also be checked for downloads initiated through file coordination.
425        ///
426        /// Error cases:
427        /// ------------
428        /// If the download fails because the item was deleted on the server, the call should
429        /// fail with the NSFileProviderErrorNoSuchItem error. In that case, the system
430        /// will consider the item has been removed from the domain and will attempt to
431        /// delete it from disk. In case that deletion fails because there are local
432        /// changes on this item, the system will re-create the item using createItemBasedOnTemplate,
433        /// passing the NSFileProviderCreateItemDeletionConflicted flag.
434        ///
435        /// If the user does not have access to the content of the file, the provider
436        /// can fail the call with NSCocoaErrorDomain and code NSFileReadNoPermissionError.
437        /// That error will then be presented to the user. The extension can also report
438        /// the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable
439        /// in case the item cannot be fetched because of the current state of the system / domain.
440        /// In those cases, the system will present an appropriate error message and back off
441        /// until the next time it is signalled.
442        ///
443        /// Any other error, including crashes of the extension process, will be considered to be transient
444        /// and will cause the download to be retried.
445        ///
446        /// Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain.
447        ///
448        /// For errors which can not be represented using an existing error code in one of these domains, the extension
449        /// should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid.
450        /// The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not
451        /// be represented.
452        ///
453        /// Cancellations:
454        /// ------------
455        /// If the NSProgress returned by this method is cancelled, the extension should
456        /// call the completion handler with (nil, nil, NSUserCancelledError) in the NSProgress
457        /// cancellation handler.
458        ///
459        /// The returned NSProgress is used to show progress to the user. If the user cancels the
460        /// fetch, the extension should stop fetching the item, as it is no longer required.
461        ///
462        /// Execution time:
463        /// ---------------
464        /// The system will grant enough time to the extension to download the file. The system will interrupt the
465        /// call if it stops making progress or if download takes an unexpectedly long time. In that case, the system
466        /// will call `cancel` on the progress. The extension is then expected to quickly call the completion
467        /// handler.
468        #[unsafe(method(fetchContentsForItemWithIdentifier:version:request:completionHandler:))]
469        #[unsafe(method_family = none)]
470        unsafe fn fetchContentsForItemWithIdentifier_version_request_completionHandler(
471            &self,
472            item_identifier: &NSFileProviderItemIdentifier,
473            requested_version: Option<&NSFileProviderItemVersion>,
474            request: &NSFileProviderRequest,
475            completion_handler: &block2::DynBlock<
476                dyn Fn(*mut NSURL, *mut NSFileProviderItem, *mut NSError),
477            >,
478        ) -> Retained<NSProgress>;
479
480        #[cfg(all(
481            feature = "NSFileProviderItem",
482            feature = "NSFileProviderRequest",
483            feature = "block2"
484        ))]
485        /// Create a new item.
486        ///
487        /// The itemTemplate object describes the expected state of the newly created item,
488        /// including its location provided by parentItemIdentifier and filename. The list
489        /// of fields to conside in that object is defined by the fields parameter. Fields
490        /// not listed should be considered as not being defined.
491        ///
492        /// The url is used to transfer the content of the file from the system to the
493        /// extension. It can be nil if the item has no content. This will be the case if
494        /// the item is a folder or if the item is being reimported (flag
495        /// NSFileProviderCreateItemMayAlreadyExist set) and the file is dataless on disk.
496        /// If the item is a symbolic link, the target path is provided by the symlinkTargetPath
497        /// of the itemTemplate.
498        ///
499        /// The system is setting the itemIdentifier of the itemTemplate to a unique value that
500        /// is guaranteed to stay the same for a given item in case the creation is replayed
501        /// after a crash. That itemIdentifier is not intended to be the identifier assigned
502        /// to the item by the provider.
503        ///
504        /// In the completion block, the createdItem is expected to reflect the properties of the
505        /// newly created item, which usually means matching the properties passed in by the
506        /// template. An exception is the itemIdentifier which should be the identifier assigned
507        /// to that item by the provider rather than the identifier passed in through the template.
508        /// If the provider reuses an existing identifier, the item that used that identifier will
509        /// be removed from disk, replaced by the createdItem. If the item is a directory, the two
510        /// directories will be merged and the items from the existing one will be modified with
511        /// the NSFileProviderModifyItemMayAlreadyExist option set.
512        ///
513        /// If the provider is not able to apply all the fields at once, it should return a
514        /// set of stillPendingFields in its completion handler. In that case, the system will
515        /// attempt to modify the item later by calling modifyItem with those fields.
516        ///
517        /// The filename and contents fields should be synced together.
518        /// If synced independently, files may appear corrupted on other devices, due to
519        /// a mismatch between the file extension and the actual file data.
520        ///
521        /// If a field in the returned createdItem does not match the itemTemplate, and is
522        /// not in the list of stillPendingFields, the value from the createdItem will be
523        /// propagated to the disk. If the content of the item as described by createdItem
524        /// does not match the content from url, the provider should set shouldFetchContent
525        /// in the completion handler. The content from the provider will then be fetched
526        /// and propagated to disk.
527        ///
528        /// In case the deletion of an item from the working set could not be applied to the
529        /// disk by the system because it conflicted with a local edit of the file, the system
530        /// will attempt to create the edited item. In that case the creation call will receive
531        /// the NSFileProviderCreateItemDeletionConflicted option and the itemIdentifier in the
532        /// template will be set to the itemIdentifier of the item deleted from the working set.
533        /// The itemVersion will also be set to the last itemVersion of the item that was made
534        /// available on disk before the item was edited locally. If such a conflict happens
535        /// on a dataless item on disk, the item will be immediately deleted from the disk instead
536        /// of issuing a new creation.
537        ///
538        /// In case the NSFileProviderCreateItemMayAlreadyExist option
539        /// is passed, the content may be nil if the item is found by the system without any
540        /// associated content. In that case, you should return a nil item if you are not
541        /// able to match the created item with an existing item from the provider.
542        ///
543        /// In case of path collision with an already existing item, the provider
544        /// can either fail using -[NSError (NSFileProviderError) fileProviderErrorForCollisionWithItem:]
545        /// or resolve the collision by itself (e.g. by returning an item with a different name).
546        /// If the error is returned, the system will try to resolve the collision by itself by bouncing
547        /// away one of the items (renaming the item).
548        ///
549        /// If the imported item is refused by the extension, it should return nil for the
550        /// createdItem without any error. In that case, the source item will be deleted
551        /// from disk. In case the item represents a directory, the content will be deleted
552        /// recursively.
553        ///
554        /// If the extension does not wish to sync the item, while still
555        /// keeping the item on disk, on macOS 13.0, iOS 16.0, and later,
556        /// it should return `NSFileProviderErrorExcludedFromSync`
557        /// on the completion handler. For more details, see the header comment for that
558        /// error code.
559        /// On earlier versions of macOS, where `NSFileProviderErrorExcludedFromSync` is
560        /// unavailable, the extension could choose to respond to FileProvider API calls as
561        /// if the item is synced to it's server, but the extension only tracks the item
562        /// in it's own local database on the device. The extension must be careful to respond to
563        /// all FileProvider API calls as if the file is really synced to it's server, including
564        /// enumerations of the parent directory of that item, itemForIdentifier calls, etc.
565        ///
566        /// The progress returned by createItemBasedOnTemplate is expected to include the
567        /// upload progress of the item and will be presented in the user interface until
568        /// the completion handler is called.
569        ///
570        /// Creation is gated by the NSFileProviderItemCapabilitiesAllowsAddingSubItems
571        /// capability on the parent folder on a UI level, but direct file system changes
572        /// (e.g. from Terminal) can still result in changes that must be handled.
573        ///
574        /// Structural consistency:
575        /// -----------------------
576        /// The system guarantees that the creation is called after the creation of the
577        /// parent completed.
578        ///
579        /// File ownership:
580        /// ---------------
581        /// The file at `url` is owned by the system and is unlinked after the completion
582        /// handler is called. If the extension wishes to keep access to the content of
583        /// file after calling the completion handler, it should clone the file in its
584        /// container.
585        ///
586        /// Atomicity:
587        /// ----------
588        /// By default, the system assumes all the changes are applied non-atomically, which
589        /// means that the change or an intermediary state from the change can be observed
590        /// (for instance while enumerating the working set) while the call is in progress
591        /// (before the completion handler is called). The provider can indicate to the system
592        /// that it applies changes atomically (that is, the change cannot be observed before
593        /// the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically
594        /// in the Info.plist of the extension to YES.
595        ///
596        /// The atomicity declaration only describes the visibility of the changes, not
597        /// the ability of the provider to apply all the fields at once: a provider that applies
598        /// changes atomically might still apply a subset of the changedFields communicated
599        /// by the system and defer the remaining fields by setting the stillPendingFields
600        /// parameter in the completion handler.
601        ///
602        /// Error cases:
603        /// ------------
604        /// If the creation fails because the target directory does not exist, the extension
605        /// must fail the creation using the NSFileProviderErrorNoSuchItem error code. In
606        /// that case, the system will attempt the re-create the parent directory.
607        ///
608        /// In case the location of the new item is already in use by another item, the extension
609        /// can chose to either resolve the collision by moving one of the items
610        /// away, or reject the creation with the NSFileProviderErrorFilenameCollision
611        /// error code. In that error case, the system will be responsible for resolving the
612        /// collision, by renaming one of the colliding items. When the collision is resolved,
613        /// the system will call createItemBasedOnTemplate again.
614        ///
615        /// The extension can also report NSFileProviderErrorNotAuthenticated,
616        /// NSFileProviderErrorCannotSynchronize, or NSFileProviderErrorExcludedFromSync,
617        /// in case the modification cannot be applied because of the current state of the
618        /// system / domain. In that case, the system will present an appropriate error message
619        /// and back off until the next time it is signalled. The provider can signal the error
620        /// resolution by calling signalErrorResolved:completionHandler:.
621        ///
622        /// Any other error, including crashes of the extension process, will be considered to be transient
623        /// and will cause the creation to be retried.
624        ///
625        /// Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain.
626        ///
627        /// For errors which can not be represented using an existing error code in one of these domains, the extension
628        /// should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid.
629        /// The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not
630        /// be represented.
631        ///
632        /// Cancellations:
633        /// ------------
634        /// If the NSProgress returned by this method is cancelled, the extension should
635        /// call the completion handler with (nil, [], NO, NSUserCancelledError) in the NSProgress
636        /// cancellation handler.
637        ///
638        /// Execution time:
639        /// ---------------
640        /// The system will grant enough time to the extension to upload the file if content is passed to the call,
641        /// otherwise the call is expected to completed within a few seconds. The system will interrupt the
642        /// call if it stops making progress or if upload takes an unexpectedly long time. In that case, the system
643        /// will call `cancel` on the progress. The extension is then expected to quickly call the completion
644        /// handler.
645        #[unsafe(method(createItemBasedOnTemplate:fields:contents:options:request:completionHandler:))]
646        #[unsafe(method_family = none)]
647        unsafe fn createItemBasedOnTemplate_fields_contents_options_request_completionHandler(
648            &self,
649            item_template: &NSFileProviderItem,
650            fields: NSFileProviderItemFields,
651            url: Option<&NSURL>,
652            options: NSFileProviderCreateItemOptions,
653            request: &NSFileProviderRequest,
654            completion_handler: &block2::DynBlock<
655                dyn Fn(*mut NSFileProviderItem, NSFileProviderItemFields, Bool, *mut NSError),
656            >,
657        ) -> Retained<NSProgress>;
658
659        #[cfg(all(
660            feature = "NSFileProviderItem",
661            feature = "NSFileProviderModifyItemOptions",
662            feature = "NSFileProviderRequest",
663            feature = "block2"
664        ))]
665        /// Informs the provider that an item or its metadata have changed. More than one
666        /// property may have changed, e.g.  an item may have been renamed, moved and also
667        /// changed contents, in which case changedFields might contain [.contents,
668        /// .filename, .parentItemIdentifier, .contentModificationDate].
669        ///
670        /// If the provider is not able to apply all the fields at once, it should return a
671        /// set of stillPendingFields in its completion handler. In that case, the system will
672        /// attempt to modify the item later by calling modifyItem with those fields.
673        ///
674        /// The filename and contents fields should be synced together.
675        /// If synced independently, files may appear corrupted on other devices, due to
676        /// a mismatch between the file extension and the actual file data.
677        ///
678        /// Starting in macOS 12.0, if the set of stillPendingFields returned by the provider is
679        /// identical to the set of fields passed to modifyItem, then the system will consider that these fields
680        /// are not supported by the provider. The system will not send these fields to the provider again,
681        /// until the item is modified.
682        ///
683        /// If a field in the returned item does not match the itemTemplate, and is
684        /// not in the list of stillPendingFields, the value from the item will be
685        /// propagated to the disk. In case there is a content change and the content of
686        /// the returned item as described by item does not match the content from url,
687        /// the provider should set shouldFetchContent in the completion handler. The
688        /// content from the provider will then be fetched and propagated to disk.
689        ///
690        /// If the item modification results from the parent directory being merged into another
691        /// directory, the NSFileProviderModifyItemMayAlreadyExist flag will be passed
692        /// to the call.
693        ///
694        /// The provider can chose to merge two existing items when receiving modifyItem. In that
695        /// case, the item returned should carry the itemIdentifier of the item with which the
696        /// item will be merged and well as the resulting state of that item. The system will then
697        /// keep one of the items (the one whose itemIdentifier was returned) and remove
698        /// the other one from disk. In case of directories, the content of the two directories
699        /// is merged and sub-items will be modified with the
700        /// NSFileProviderModifyItemMayAlreadyExist flag set.
701        ///
702        /// If the extension wishes the modify item to cause the deletion of the item on disk,
703        /// it can call the completion handler with nil in place of the resulting item. If the
704        /// item is directory, the item will be kept on disk until all its children has been deleted
705        /// from the working set. The system will only apply the deletion on the disk if this
706        /// does not conflict with local edits. Otherwise, the system will attempt to re-create
707        /// the item with the NSFileProviderCreateItemDeletionConflicted option set.
708        ///
709        /// The progress returned by modifyItem is expected to include the upload progress if any,
710        /// even if the provider chose to call the completion handler before the upload finishes.
711        /// For example, the provider might decide to call the completion handler as soon as the
712        /// metadata have been stored in a local database.
713        ///
714        /// Modifications are gated by the corresponding capabilities of the item on a UI level,
715        /// but direct file system changes (e.g. from Terminal) can still result in changes that
716        /// must be handled.
717        ///
718        /// Conflict resolution:
719        /// -------------------
720        /// The system passes a `baseVersion` parameter to the modifyItem call. This
721        /// baseVersion describes the latest version of the file which was reflected on disk.
722        /// This parameter can be used to detect conflicts with remote edits.
723        ///
724        /// For instance, if content version A of the file was downloaded to the local system, and
725        /// the content was modified locally, the modifyItem call will receive baseVersion of A. If the server
726        /// has in the meantime received another content edit of the same file, the server may
727        /// have content version C. In this case, the extension can detect the mismatching baseVersion,
728        /// and decide how to resolve the conflict. The extension informs the system of how it
729        /// wishes to resolve the conflict by returning the resolved metadata on the completion handler.
730        /// As an example resolution, if the extension informs that it wishes for the remote version
731        /// of the item to be on disk (and to ignore the local edits), it should return the new
732        /// contentVersion in the completion handler's item. The system will subsequently call
733        /// fetchContents to retrieve the new contents and replace them on disk.
734        ///
735        /// The `baseVersion` might contain one or both component set to
736        /// `+[NSFileProviderItemVersion beforeFirstSyncComponent]`, in case
737        /// there has never been a version for which the item on disk and the item in the provider
738        /// were known to be in sync.
739        ///
740        /// Structural consistency and Cycle handling:
741        /// ------------------------------------------
742        /// In case the parentItemIdentifier is modified, the system guarantees that the new
743        /// parent has been created and the creation completed before the call to modifyItem
744        /// is issued.
745        ///
746        /// The system guarantees that modifyItem called after local changes from the user will
747        /// never create a cycle: that is all items will always be a descendent of either the
748        /// root item or the trash item.
749        ///
750        /// However, cycles that are caused by concurrent local changes by the user and changes
751        /// on the remote server can also create cycles. This is handled by the system as a
752        /// conflict. This means the provider must validate that the call of modifyItem is not
753        /// creating a cycle with a change it observed from the server. If such a cycle is
754        /// detected, the provider must fix the conflict by breaking the cycle, and return the
755        /// state of the item after resolving that conflict. If the resolution affects other
756        /// items as well, updates for those other items must be published on the working set.
757        ///
758        /// File ownership:
759        /// ---------------
760        /// The file at `url` is owned by the system and is unlinked after the completion
761        /// handler is called. If the extension wishes to keep access to the content of
762        /// file after calling the completion handler, it should clone the file in its
763        /// container.
764        ///
765        /// Atomicity:
766        /// ----------
767        /// By default, the system assumes all the changes are applied non-atomically, which
768        /// means that the change or an intermediary state from the change can be observed
769        /// (for instance while enumerating the working set) while the call is in progress
770        /// (before the completion handler is called). The provider can indicate to the system
771        /// that it applies changes atomically (that is, the change cannot be observed before
772        /// the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically
773        /// in the Info.plist of the extension to YES.
774        ///
775        /// The atomicity declaration only describes the visibility of the changes, not
776        /// the ability of the provider to apply all the fields at once: a provider that applies
777        /// changes atomically might still apply a subset of the changedFields communicated
778        /// by the system and defer the remaining fields by setting the stillPendingFields
779        /// parameter in the completion handler.
780        ///
781        /// Error cases:
782        /// ------------
783        /// The extension may fail the modification if the modified item does not exist
784        /// anymore. In that case, the extension should fail the call the
785        /// NSFileProviderErrorNoSuchItem error code. The system will attempt to delete
786        /// the item on disk. If the item on disk actually has changes since this call
787        /// to modifyItem, then it will be re-created by a call to createItemBasedOnTemplate.
788        /// Likewise, if the item is reparented to a parent that no longer exists, the extension
789        /// may return a NSFileProviderErrorNoSuchItem error with the parent item.
790        ///
791        /// In case the modification updates the location of the item and another item is
792        /// already known at this location, the extension can chose to either resolve the
793        /// collision by moving one of the items away, or reject the modification with
794        /// the NSFileProviderErrorFilenameCollision error code. In that error case,
795        /// the system will be responsible for resolving the collision, by renaming one of
796        /// the colliding items. When the collision is resolved, the system will call
797        /// modifyItem again.
798        ///
799        /// In case the NSFileProviderModifyItemFailOnConflict option is passed, the provider should
800        /// fail the modification if the baseVersion does not match the version on the server. It
801        /// will be up to the system to merge the conflict and call modifyItem again with an
802        /// updated baseVersion.
803        ///
804        /// The extension can also report NSFileProviderErrorNotAuthenticated,
805        /// NSFileProviderErrorCannotSynchronize, or NSFileProviderErrorExcludedFromSync,
806        /// in case the modification cannot be applied because of the current state of the
807        /// system / domain. In that case, the system will present an appropriate error message
808        /// and back off until the next time it is signalled. The provider can signal the error
809        /// resolution by calling signalErrorResolved:completionHandler:.
810        ///
811        /// Any other error, including crashes of the extension process, will be considered to be transient
812        /// and will cause the modification to be retried.
813        ///
814        /// Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain.
815        ///
816        /// For errors which can not be represented using an existing error code in one of these domains, the extension
817        /// should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid.
818        /// The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not
819        /// be represented.
820        ///
821        /// Cancellations:
822        /// ------------
823        /// If the NSProgress returned by this method is cancelled, the extension should
824        /// call the completion handler with (nil, [], NO, NSUserCancelledError) in the NSProgress
825        /// cancellation handler.
826        ///
827        /// Execution time:
828        /// ---------------
829        /// The system will grant enough time to the extension to upload the file if content is passed to the call,
830        /// otherwise the call is expected to completed within a few seconds. The system will interrupt the
831        /// call if it stops making progress or if upload takes an unexpectedly long time. In that case, the system
832        /// will call `cancel` on the progress. The extension is then expected to quickly call the completion
833        /// handler.
834        #[unsafe(method(modifyItem:baseVersion:changedFields:contents:options:request:completionHandler:))]
835        #[unsafe(method_family = none)]
836        unsafe fn modifyItem_baseVersion_changedFields_contents_options_request_completionHandler(
837            &self,
838            item: &NSFileProviderItem,
839            version: &NSFileProviderItemVersion,
840            changed_fields: NSFileProviderItemFields,
841            new_contents: Option<&NSURL>,
842            options: NSFileProviderModifyItemOptions,
843            request: &NSFileProviderRequest,
844            completion_handler: &block2::DynBlock<
845                dyn Fn(*mut NSFileProviderItem, NSFileProviderItemFields, Bool, *mut NSError),
846            >,
847        ) -> Retained<NSProgress>;
848
849        #[cfg(all(
850            feature = "NSFileProviderItem",
851            feature = "NSFileProviderRequest",
852            feature = "block2"
853        ))]
854        /// Delete an item forever.
855        ///
856        /// This is called when the user deletes an item that was already in the Trash and
857        /// the item should no longer appear there after this call.  This call should
858        /// remove the item from the working set.
859        ///
860        /// This call receives an optional baseVersion which represent the version of the
861        /// item we are trying to delete.
862        ///
863        /// Unless the NSFileProviderDeleteItemRecursive options is passed, the
864        /// deletion of a directory should be non-recursive. If the deletion is recursive
865        /// the provider should take care of reporting the deletion of all the deleted
866        /// items through the working set.
867        ///
868        /// Delete is gated by the capabilities of the removed item with
869        /// NSFileProviderItemCapabilitiesAllowsDeleting.
870        ///
871        /// Modifications are gated by NSFileProviderItemCapabilitiesAllowsDeleting
872        /// of the item on a UI level, but direct file system changes (e.g. from Terminal)
873        /// can still result in changes that must be handled.
874        ///
875        /// Atomicity:
876        /// ----------
877        /// By default, the system assumes all the changes are applied non-atomically, which
878        /// means that the change or an intermediary state from the change can be observed
879        /// (for instance while enumerating the working set) while the call is in progress
880        /// (before the completion handler is called). The provider can indicate to the system
881        /// that it applies changes atomically (that is, the change cannot be observed before
882        /// the completion handler is called) by setting the key NSExtensionFileProviderAppliesChangesAtomically
883        /// in the Info.plist of the extension to YES.
884        ///
885        /// Error cases:
886        /// ------------
887        /// The extension may fail the deletion in different scenarios, for instance because
888        /// the baseVersion is out of date or because the user does not have permissions to
889        /// delete the item. In that case the extension should fail the call with the
890        /// NSFileProviderErrorDeletionRejected error code which will cause the system to
891        /// re-create the deleted item on disk based on the latest metadata available from
892        /// the extension.
893        ///
894        /// If the options don't include NSFileProviderDeleteItemRecursive and the
895        /// deletion targets a non-empty directory, the extension must reject the deletion
896        /// with the NSFileProviderErrorDirectoryNotEmpty error code. This error can also
897        /// be reported in case some children of the directory cannot be deleted when
898        /// receiving the NSFileProviderDeleteItemRecursive option. In both cases,
899        /// the system will re-create the deleted item on disk based on the latest metadata
900        /// available from the extension.
901        ///
902        /// If the deletion targets an item that is unknown from the extension because
903        /// that item may have already been deleted remotely, then the extension should
904        /// report a success.
905        ///
906        /// The extension can also report the NSFileProviderErrorNotAuthenticated,
907        /// NSFileProviderErrorServerUnreachable, or NSFileProviderErrorCannotSynchronize
908        /// in case the deletion cannot be applied because of the current state of the
909        /// system / domain. In that case, the system will present an appropriate error
910        /// message and back off until the next time it is signalled.
911        ///
912        /// Any other error, including crashes of the extension process, will be considered to be transient
913        /// and will cause the deletion to be retried.
914        ///
915        /// Errors must be in one of the following domains: NSCocoaErrorDomain, NSFileProviderErrorDomain.
916        ///
917        /// For errors which can not be represented using an existing error code in one of these domains, the extension
918        /// should construct an NSError with domain NSCocoaErrorDomain and code NSXPCConnectionReplyInvalid.
919        /// The extension should set the NSUnderlyingErrorKey in the NSError's userInfo to the error which could not
920        /// be represented.
921        ///
922        /// Cancellations:
923        /// ------------
924        /// If the NSProgress returned by this method is cancelled, the extension should
925        /// call the completion handler with (NSUserCancelledError) in the NSProgress
926        /// cancellation handler.
927        ///
928        /// Execution time:
929        /// ---------------
930        /// This call is not expected to take more than a few seconds to complete. The system will interrupt the
931        /// call if it stops making progress or if the deletion takes an unexpectedly long time. In that case,the system
932        /// will call `cancel` on the progress. The extension is then expected to quickly call the completion
933        /// handler.
934        #[unsafe(method(deleteItemWithIdentifier:baseVersion:options:request:completionHandler:))]
935        #[unsafe(method_family = none)]
936        unsafe fn deleteItemWithIdentifier_baseVersion_options_request_completionHandler(
937            &self,
938            identifier: &NSFileProviderItemIdentifier,
939            version: &NSFileProviderItemVersion,
940            options: NSFileProviderDeleteItemOptions,
941            request: &NSFileProviderRequest,
942            completion_handler: &block2::DynBlock<dyn Fn(*mut NSError)>,
943        ) -> Retained<NSProgress>;
944
945        #[cfg(feature = "block2")]
946        /// Signal the end of import of on-disk items.
947        ///
948        /// This is called after a reimport of on-disk items has been triggered by either
949        /// `-[NSFileProviderManager reimportItemsBelowItemWithIdentifier:completionHandler:]`
950        /// or after a new domain is created using
951        /// `+[NSFileProviderManager importDomain:fromDirectoryAtURL:completionHandler:]` or
952        /// `+[NSFileProviderManager addDomain:completionHandler:]`.
953        ///
954        /// `reimport` can also be started by the system independently from any request by the
955        /// provider. The provider can detect those events by monitoring
956        /// `-[NSFileProviderDomain backingStoreIdentity]`.
957        ///
958        /// During import, found items will be created via the
959        /// -[NSFileProviderExtension createItemBasedOnTemplate:fields:contents:options:completionHandler:]
960        /// call with the NSFileProviderCreateItemMayAlreadyExist flag set.
961        /// At the end of an import the -[NSFileProviderExtension importDidFinishWithCompletionHandler:]
962        /// is called.
963        ///
964        /// The system will attempt to import items as they are accessed by the user or applications. Import
965        /// of the other items is scheduled by the system as a background task. That task may be delayed,
966        /// for instance in low-power situations, or when the system is under heavy load. The provider can
967        /// force the system to process a folder and its direct children by issuing a coordination request
968        /// on that folder.
969        ///
970        /// Execution time:
971        /// ---------------
972        /// This call is not expected to take more than a few seconds to complete.
973        #[optional]
974        #[unsafe(method(importDidFinishWithCompletionHandler:))]
975        #[unsafe(method_family = none)]
976        unsafe fn importDidFinishWithCompletionHandler(
977            &self,
978            completion_handler: &block2::DynBlock<dyn Fn()>,
979        );
980
981        #[cfg(feature = "block2")]
982        /// Called by the system if the set of materialized items changes.
983        ///
984        /// Materialized items are items that have synced to disk and are not
985        /// dataless.  They may contain a mix of dataless and materialized files and
986        /// directories, but in any case, all their children are represented on disk.
987        /// Traversals of dataless directories by applications trigger an enumeration
988        /// against the file provider extension; traversals of materialized directories
989        /// do not.  It is the responsability of the file provider extension to notify
990        /// the system on remote changes of these files: there is no alternative cache
991        /// invalidation mechanism.
992        ///
993        /// If the extension doesn't keep track of the materialized set, it will have to
994        /// notify the system of all remote changes.  In that case the working set is the
995        /// entire dataset.  The system may drop items whose parent isn't materialized, to
996        /// avoid unnecessary disk usage.  This saves some I/O, but isn't optimal.  The
997        /// filtering by parentItemIdentifier is better done in the extension;  ideally,
998        /// it would even be done server-side.  A hybrid model is possible, where some
999        /// filtering is done server-side, and some finer filtering is done client-side.
1000        ///
1001        /// The file provider extension should therefore keep a list of the identifiers of
1002        /// the materialized directories.  This method is called when a new directory is
1003        /// materialized or when a materialized directory is rendered dataless.
1004        ///
1005        /// To enumerate the set of materialized containers,
1006        /// - Call -enumeratorForMaterializedItems on the instance of
1007        /// NSFileProviderManager corresponding to your domain;
1008        /// - Implement the NSFileProviderEnumerationObserver and
1009        /// NSFileProviderChangeObserver on an object;
1010        /// - Pass that object to the enumerator;
1011        /// - Use the identifiers of items or changes you receive to note the
1012        /// materialization status in your database.
1013        ///
1014        /// When an item is created, modified or deleted remotely, the file provider
1015        /// extension should check whether its parentItemIdentifier is in the materialized
1016        /// set.  If it is, the extension needs to inform the system so the system may
1017        /// create, modify or delete the file or directory (initially dataless) on disk.
1018        /// In the case when an item is reparented, the test should be that either the new
1019        /// or the old parentItemIdentifier is in the materialized set.  No need to pretend
1020        /// that the iten was deleted if the new parentItemIdentifier is no longer in the
1021        /// materialized set: the system will know what to do with an unknown parent
1022        /// identifier.
1023        ///
1024        /// To notify the system of this created, modified or deleted item,
1025        /// - Call -signalEnumeratorForContainerItemIdentifier: on the working set, i.e the
1026        /// container identified by NSFileProviderWorkingSetContainerItemIdentifier;
1027        /// - Include this item in the next enumeration of the working set.
1028        ///
1029        /// Since this method is called on every change of the set of materialized items,
1030        /// it is advisable to use it to set a flag and perform any resulting work as a
1031        /// timed task rather than performing any work directly.
1032        ///
1033        /// Execution time:
1034        /// ---------------
1035        /// This call is not expected to take more than a few seconds to complete.
1036        #[optional]
1037        #[unsafe(method(materializedItemsDidChangeWithCompletionHandler:))]
1038        #[unsafe(method_family = none)]
1039        unsafe fn materializedItemsDidChangeWithCompletionHandler(
1040            &self,
1041            completion_handler: &block2::DynBlock<dyn Fn()>,
1042        );
1043
1044        #[cfg(feature = "block2")]
1045        /// Called by the system when the set of pending items is refreshed.
1046        ///
1047        /// The pending enumerator lists all the items for which a change has been observed either
1048        /// on the disk or in the working set more than one second ago and that change hasn't been
1049        /// applied on the other side yet. An item can appear in the pending set for various reasons:
1050        /// - the system is under load and cannot process all the events in a timely fashion
1051        /// - a long running operation is scheduled or running for the item to be in sync (for instance,
1052        /// the download or the upload of a new content)
1053        /// - an error occurred, in which case the error will be set on the item as `downloadError` if
1054        /// it occurred when applying a change to the disk, or `uploadError` in the other way around.
1055        ///
1056        /// The pending set will only include items that comply to the following rules:
1057        /// - They have been queued for changes for more time than the refresh interval;
1058        /// - The items are already known by the provider.
1059        ///
1060        /// These constraints imply that initial transfer of a file from the disk to the provider will not
1061        /// be listed in the pending set, even though the transfer could take several minutes to complete
1062        ///
1063        /// Furthermore, the pending set can only contain a limited number of items.
1064        /// The pending set provides an easy way to design an "in progress" UI containing a few items
1065        /// and to detect whether there's any activity pending on the system.
1066        /// In case the pending set reached its maximum size items, newly pending items won't be included
1067        /// in it. Already present items in the pending set will remain until they no longer are pending.
1068        ///
1069        /// The pending set is refreshed regurlary but only if there are meaningful changes:
1070        /// new pending items, items that were pending but are not anymore (deletions from the set),
1071        /// or domain version changed and set is not empty
1072        ///
1073        /// To enumerate the set of pending items,
1074        /// - Call -enumeratorForPendingItems on the instance of
1075        /// NSFileProviderManager corresponding to your domain;
1076        /// - Implement the NSFileProviderEnumerationObserver and
1077        /// NSFileProviderChangeObserver on an object;
1078        /// - Pass that object to the enumerator;
1079        /// - It will get called upon change to the set.
1080        ///
1081        /// This method is regularly called when changes happen to the pending set.
1082        /// implementeers are advised that this call will not happen as soon as an item is pending.
1083        /// Thus, implementeers should not use the pending set to detect when a change happens.
1084        /// The pending set will only contain items that were pending for a least one second before the
1085        /// last refresh date.
1086        ///
1087        /// Execution time:
1088        /// ---------------
1089        /// This call is not expected to take more than a few seconds to complete.
1090        #[optional]
1091        #[unsafe(method(pendingItemsDidChangeWithCompletionHandler:))]
1092        #[unsafe(method_family = none)]
1093        unsafe fn pendingItemsDidChangeWithCompletionHandler(
1094            &self,
1095            completion_handler: &block2::DynBlock<dyn Fn()>,
1096        );
1097    }
1098);
1099
1100extern_protocol!(
1101    /// Protocol to implement if the provider instance supports fetching incremental content changes.
1102    ///
1103    /// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderincrementalcontentfetching?language=objc)
1104    pub unsafe trait NSFileProviderIncrementalContentFetching: NSObjectProtocol {
1105        #[cfg(all(
1106            feature = "NSFileProviderItem",
1107            feature = "NSFileProviderRequest",
1108            feature = "block2"
1109        ))]
1110        /// Update a previously provided item to a new version.
1111        ///
1112        /// If the system already has a version of an item and learns that a new version is
1113        /// available, it may call this method to update the existing version to a new
1114        /// version.
1115        ///
1116        /// The semantics of the requestedVersion parameter are the same as for the non-delta update method above.
1117        #[unsafe(method(fetchContentsForItemWithIdentifier:version:usingExistingContentsAtURL:existingVersion:request:completionHandler:))]
1118        #[unsafe(method_family = none)]
1119        unsafe fn fetchContentsForItemWithIdentifier_version_usingExistingContentsAtURL_existingVersion_request_completionHandler(
1120            &self,
1121            item_identifier: &NSFileProviderItemIdentifier,
1122            requested_version: Option<&NSFileProviderItemVersion>,
1123            existing_contents: &NSURL,
1124            existing_version: &NSFileProviderItemVersion,
1125            request: &NSFileProviderRequest,
1126            completion_handler: &block2::DynBlock<
1127                dyn Fn(*mut NSURL, *mut NSFileProviderItem, *mut NSError),
1128            >,
1129        ) -> Retained<NSProgress>;
1130    }
1131);
1132
1133extern_protocol!(
1134    /// [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderservicing?language=objc)
1135    pub unsafe trait NSFileProviderServicing: NSObjectProtocol {
1136        #[cfg(all(
1137            feature = "NSFileProviderItem",
1138            feature = "NSFileProviderService",
1139            feature = "block2"
1140        ))]
1141        /// A file provider can implemement this method to return service sources that provide custom
1142        /// communication channels to client applications.
1143        ///
1144        /// The service sources must be tied to the item identified by
1145        /// `itemIdentifier.`Client applications can retrieve the list of supported services by calling
1146        /// `-[NSFileManager`getFileProviderServicesForItemAtURL:] for a specific item URL.
1147        ///
1148        /// Cancellations:
1149        /// ------------
1150        /// If the NSProgress returned by this method is cancelled, the extension should
1151        /// call the completion handler with (nil, NSUserCancelledError) in the NSProgress
1152        /// cancellation handler.
1153        ///
1154        /// Execution time:
1155        /// ---------------
1156        /// This method is not expected to take more than a few seconds to complete the retrieval of the
1157        /// thumbnails. The system will call `cancel` on the progress if the
1158        /// operation takes too much time. The extension is then expected to quickly call the completion
1159        /// handler.
1160        #[unsafe(method(supportedServiceSourcesForItemIdentifier:completionHandler:))]
1161        #[unsafe(method_family = none)]
1162        unsafe fn supportedServiceSourcesForItemIdentifier_completionHandler(
1163            &self,
1164            item_identifier: &NSFileProviderItemIdentifier,
1165            completion_handler: &block2::DynBlock<
1166                dyn Fn(*mut NSArray<ProtocolObject<dyn NSFileProviderServiceSource>>, *mut NSError),
1167            >,
1168        ) -> Retained<NSProgress>;
1169    }
1170);
1171
1172extern_protocol!(
1173    /// Protocol to implement if the provider supports fetching thumbnails for its items.
1174    ///
1175    /// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderthumbnailing?language=objc)
1176    pub unsafe trait NSFileProviderThumbnailing: NSObjectProtocol {
1177        #[cfg(all(
1178            feature = "NSFileProviderItem",
1179            feature = "block2",
1180            feature = "objc2-core-foundation"
1181        ))]
1182        /// The system calls this method to fetch thumbnails.
1183        ///
1184        /// The
1185        /// `perThumbnailCompletionHandler`should be called for each thumbnail, and
1186        /// `completionHandler`only after all the per thumbnail completion blocks.
1187        ///
1188        /// In the event of a global error, the implementation is allowed to skip calling
1189        /// the
1190        /// `perThumbnailCompletionHandler`for individual thumbnails. In that case,
1191        /// the
1192        /// `completionHandler's`error parameter would apply to all item identifiers
1193        /// for which
1194        /// `perThumbnailCompletionHandler`had not been called.
1195        ///
1196        /// If there is no thumbnail for a given item, the
1197        /// `perThumbnailCompletionHandler`should be called with its
1198        /// `imageData`and
1199        /// `error`parameters both
1200        /// set to nil.
1201        ///
1202        /// If the system decides that an in-flight thumbnail request is not needed anymore,
1203        /// it will call the returned
1204        /// `NSProgress`object's
1205        /// `-cancel`method,
1206        /// at which time the implementation should clean up any held resources.
1207        ///
1208        /// The system will cache the thumbnail for the item, and the cache will be
1209        /// invalidated when itemVersion.contentVersion changes.
1210        ///
1211        /// Thread safety:
1212        /// ------------
1213        ///
1214        /// The
1215        /// `perThumbnailCompletionHandler`may be called from multiple threads
1216        /// concurrently.
1217        ///
1218        /// Cancellations:
1219        /// ------------
1220        /// If the NSProgress returned by this method is cancelled, the extension should
1221        /// call the completion handler with (NSUserCancelledError) in the NSProgress
1222        /// cancellation handler.
1223        ///
1224        /// Execution time:
1225        /// ---------------
1226        /// This method is not expected to take more than a few tens seconds to complete the retrieval of the
1227        /// services exposed on the item. The system will call `cancel` on the progress if the
1228        /// operation takes too much time. The extension is then expected to quickly call the completion
1229        /// handler.
1230        #[unsafe(method(fetchThumbnailsForItemIdentifiers:requestedSize:perThumbnailCompletionHandler:completionHandler:))]
1231        #[unsafe(method_family = none)]
1232        unsafe fn fetchThumbnailsForItemIdentifiers_requestedSize_perThumbnailCompletionHandler_completionHandler(
1233            &self,
1234            item_identifiers: &NSArray<NSFileProviderItemIdentifier>,
1235            size: CGSize,
1236            per_thumbnail_completion_handler: &block2::DynBlock<
1237                dyn Fn(NonNull<NSFileProviderItemIdentifier>, *mut NSData, *mut NSError),
1238            >,
1239            completion_handler: &block2::DynBlock<dyn Fn(*mut NSError)>,
1240        ) -> Retained<NSProgress>;
1241    }
1242);
1243
1244extern_protocol!(
1245    /// [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileprovidercustomaction?language=objc)
1246    pub unsafe trait NSFileProviderCustomAction: NSObjectProtocol {
1247        #[cfg(all(
1248            feature = "NSFileProviderActions",
1249            feature = "NSFileProviderItem",
1250            feature = "block2"
1251        ))]
1252        /// Perform a custom action identified by `actionIdentifier`, on items identified by
1253        /// `itemIdentifiers`.
1254        ///
1255        /// Custom actions are defined in the File Provider Extension's Info.plist, under the
1256        /// `NSExtensionFileProviderActions` key. The format of this key is identical to actions
1257        /// defined in a FileProviderUI extension.
1258        ///
1259        /// Cancellations:
1260        /// ------------
1261        /// If the NSProgress returned by this method is cancelled, the extension should
1262        /// call the completion handler with (NSUserCancelledError) in the NSProgress
1263        /// cancellation handler.
1264        #[unsafe(method(performActionWithIdentifier:onItemsWithIdentifiers:completionHandler:))]
1265        #[unsafe(method_family = none)]
1266        unsafe fn performActionWithIdentifier_onItemsWithIdentifiers_completionHandler(
1267            &self,
1268            action_identifier: &NSFileProviderExtensionActionIdentifier,
1269            item_identifiers: &NSArray<NSFileProviderItemIdentifier>,
1270            completion_handler: &block2::DynBlock<dyn Fn(*mut NSError)>,
1271        ) -> Retained<NSProgress>;
1272    }
1273);
1274
1275extern_protocol!(
1276    /// Protocol to implement for managing UserInteraction alerts.
1277    ///
1278    /// See also [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileprovideruserinteractionsuppressing?language=objc)
1279    pub unsafe trait NSFileProviderUserInteractionSuppressing: NSObjectProtocol {
1280        /// Suppression management:
1281        ///
1282        /// The extension may choose to give the user the option to suppress certain UserInteraction alerts.
1283        /// In order to do so, the extension must both implement NSFileProviderUserInteractionSuppressing, as well as
1284        /// configure the desired UserInteractions in the Info.plist with the `SuppressionIdentifier` field.
1285        ///
1286        /// When FileProvider needs to evaluate whether to display a UserInteraction alert, it will call
1287        /// -[NSFileProviderUserInteractionSuppressing isInteractionSuppressedForIdentifier:]. When the user indicates that they do not
1288        /// wish to see a given SuppressionIdentifiers's alert again, FileProvider will call
1289        /// -[NSFileProviderUserInteractionSuppressing setInteractionSuppressed:forIdentifier:].
1290        ///
1291        /// The extension can choose whether the suppression should apply only to the domain upon which
1292        /// -[NSFileProviderUserInteractionSuppressing setInteractionSuppressed:forIdentifier:] was called, or if it should apply to all
1293        /// domains for their provider. For instance, the extension could choose to suppress future alerts related
1294        /// to adding an item to a shared folder across all domains, after the user chooses to suppress the alerts
1295        /// in a specific domain's context. Or, the extension could choose to only suppress that alert for the
1296        /// specific domain it was displayed within, and in the future, the user would see the same alert in the same
1297        /// context, if they take the same action in another domain.
1298        ///
1299        /// Execution time:
1300        /// ---------------
1301        /// This method is expected to complete immediately.
1302        #[unsafe(method(setInteractionSuppressed:forIdentifier:))]
1303        #[unsafe(method_family = none)]
1304        unsafe fn setInteractionSuppressed_forIdentifier(
1305            &self,
1306            suppression: bool,
1307            suppression_identifier: &NSString,
1308        );
1309
1310        #[unsafe(method(isInteractionSuppressedForIdentifier:))]
1311        #[unsafe(method_family = none)]
1312        unsafe fn isInteractionSuppressedForIdentifier(
1313            &self,
1314            suppression_identifier: &NSString,
1315        ) -> bool;
1316    }
1317);
1318
1319extern_protocol!(
1320    /// [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderdomainstate?language=objc)
1321    pub unsafe trait NSFileProviderDomainState: NSObjectProtocol {
1322        #[cfg(feature = "NSFileProviderDomain")]
1323        /// Version of the domain.
1324        ///
1325        /// The domain version is an opaque value assigned by the provider. It is read by the system in the
1326        /// completion handler for createItemBasedOnTemplate, modifyItem, deleteItem and itemForIdentifier, as
1327        /// well as in the finish calls when enumerating the working set. The read is guaranteed to happen
1328        /// on the same dispatch queue the completion handler was called on.
1329        ///
1330        /// When the system discovers a change on disk, it associates that change to the currently known
1331        /// domain version. When that change get communicated to the extension, that version is included in
1332        /// the NSFileProviderRequest object passed by the system to the extension. As a consequence, the
1333        /// provider can use the domain version to identify the state of the system when a change was made on disk.
1334        ///
1335        /// The provider is responsible for defining when the domain version changes. When that value is
1336        /// updated, the provider must notify the system by signaling the working set.
1337        ///
1338        /// The system ignore any domain version that is smaller than the previously known version.
1339        #[unsafe(method(domainVersion))]
1340        #[unsafe(method_family = none)]
1341        unsafe fn domainVersion(&self) -> Retained<NSFileProviderDomainVersion>;
1342
1343        /// Global state of the domain.
1344        ///
1345        /// Use this dictionary to add state information to the domain. It is accessible to predicates for
1346        /// User Interactions, FileProvider Actions, and FileProviderUI Actions, via the top-level `domainUserInfo` context
1347        /// key.
1348        ///
1349        /// This dictionary must only contain key and value classes in the following list:
1350        /// NSString, NSNumber, NSDate, and NSPersonNameComponents.
1351        ///
1352        /// The system expects the domainVersion to be updated when the value of the userInfo property
1353        /// changes.
1354        #[unsafe(method(userInfo))]
1355        #[unsafe(method_family = none)]
1356        unsafe fn userInfo(&self) -> Retained<NSDictionary>;
1357    }
1358);
1359
1360extern_protocol!(
1361    /// [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderpartialcontentfetching?language=objc)
1362    pub unsafe trait NSFileProviderPartialContentFetching: NSObjectProtocol {
1363        #[cfg(all(
1364            feature = "NSFileProviderItem",
1365            feature = "NSFileProviderRequest",
1366            feature = "block2"
1367        ))]
1368        /// Download the requested extent of an item for the given identifier and return it via the completion
1369        /// handler.  If this protocol is not implemented the system defaults to fetchContentsForItemWithIdentifier.
1370        ///
1371        /// The requestedVersion parameter specifies which version should be returned. This version will always be
1372        /// specified by the system so as to prevent extents from different versions from being written into the same
1373        /// file. The system tolerates a version mismatch for the first materialization of a fully dataless file (strictVersion=NO).
1374        ///
1375        /// The requested range is
1376        /// <location
1377        /// , length>.  The implementation can provide any properly aligned range that
1378        /// covers the requested range (including the entire item).  The system provides the minimal alignment value.
1379        /// The location (or start offset) of the fetched range should be a multiple of this value for it to be considered
1380        /// properly aligned. The length of the fetched range should be a multiple of this value, with an exception for
1381        /// the end of the file, checked against the documentSize attribute the implementation supplied for this item.
1382        /// The alignment value should not be expected to be stable across reboots. It is guaranteed by the system to be
1383        /// a power of two.
1384        /// In addition to the content the extension needs to fill in fetchedRange with either the requestest range,
1385        /// <location
1386        /// , length>, or indicate full materialization with,
1387        /// <
1388        /// 0, file size>.
1389        ///
1390        /// On-disk layout:
1391        /// ---------------
1392        /// The retrieved content at `fileContents` URL must be a regular file on the same volume as the user-visible URL.
1393        /// A suitable location can be retrieved using -[NSFileProviderManager temporaryDirectoryURLWithError:].
1394        /// The file contents outside of the fetched range are ignored by the system. The system only requires the file
1395        /// to be at least as large as the end of the fetched range. For instance, if the fetchedRange is {offset:0x100000, length:0x1000},
1396        /// the file size must be at least 0x101000 bytes. Any data (or lack thereof) beyond the fetched range is ignored.
1397        ///
1398        /// The fetched range must be stored in this file at the same offset as the range indicates.
1399        /// For instance if the retrievedRange  is {offset:0x100000, length:0x1000} then it should actually be at offset 0x100000 in the
1400        /// `fileContents` file. The ranges {0, 0x100000}, and {0x101000, EOF} can be anything including sparse ranges.
1401        ///
1402        /// Concurrent Downloads:
1403        /// ---------------
1404        /// The system will call fetchContents concurrently if there are multiple outstanding file download requests.
1405        /// The provider can control the concurrency by setting the key NSExtensionFileProviderDownloadPipelineDepth
1406        /// in the Info.plist of the extension to the number of concurrent downloads that the system should create
1407        /// per domain. This number must be between 1 and 128, inclusive.
1408        ///
1409        /// File ownership:
1410        /// ---------------
1411        /// The system clones and unlinks the received fileContents. The extension should not mutate the corresponding
1412        /// file after calling the completion handler. If the extension wishes to keep a copy of the content, it must
1413        /// provide a clone of the that content as the URL passed to the completion handler.
1414        ///
1415        /// In case the extension or the system crashes between the moment the completion handler is called and the
1416        /// moment the system unlinks the file, the file may unexpectedly still be on disk the next time an instance
1417        /// of the extension is created. The extension is then responsible for deleting that file.
1418        ///
1419        /// Disallowing processes from fetching items:
1420        /// ---------------
1421        ///
1422        /// The system automatically downloads files on POSIX accesses. The extension may wish to disallow this class of
1423        /// downloads for specific applications.
1424        ///
1425        /// The extension can set an array of strings into the UserDefault key
1426        /// "NSFileProviderExtensionNonMaterializingProcessNames". A process whose executable's filename on disk is an
1427        /// exact match for an entry in this array will not be allowed to fetch items in the extension's domains. The comparison
1428        /// is case sensitive.
1429        ///
1430        /// In macOS 11.0 and later, this list will be checked when a download is initiated through a POSIX filesystem call.
1431        /// In macOS 11.4 and later, this list will also be checked for downloads initiated through file coordination.
1432        ///
1433        /// Error cases:
1434        /// ------------
1435        /// If the download fails because the item is unknown, the call should
1436        /// fail with the NSFileProviderErrorNoSuchItem error. In that case, the system
1437        /// will consider the item has been removed from the domain and will attempt to
1438        /// delete it from disk. In case that deletion fails because there are local
1439        /// changes on this item, the system will re-create the item using createItemBasedOnTemplate.
1440        ///
1441        /// If the user does not have access to the content of the file, the provider
1442        /// can fail the call with NSCocoaErrorDomain and code NSFileReadNoPermissionError.
1443        /// That error will then be presented to the user. The extension can also report
1444        /// the NSFileProviderErrorNotAuthenticated, NSFileProviderErrorServerUnreachable
1445        /// in case the item cannot be fetched because of the current state of the system / domain.
1446        /// In those cases, the system will present an appropriate error message and back off
1447        /// until the next time it is signalled.
1448        ///
1449        /// If the requested version cannot be retrieved, the provider can choose to provide a different
1450        /// version of the file, unless NSFileProviderFetchContentsOptionsStrictVersioning  is set. In this case,
1451        /// the provider should fail with NSFileProviderErrorVersionNoLongerAvailable.
1452        /// If some content is returned, the item must have the corresponding version. The system will detect
1453        /// any mismatch and handle it as a remote update.
1454        /// For the reading application, the materialization will fail with the same error as reading from
1455        /// a dataless file that got remotely updated (-1/errno=ESTALE). Upon retry the new version will be
1456        /// requested by the system.
1457        ///
1458        /// Any other error will be considered to be transient and will cause the
1459        /// download to be retried.
1460        ///
1461        /// Cancellations:
1462        /// ------------
1463        /// If the NSProgress returned by this method is cancelled, the extension should
1464        /// call the completion handler with (nil, nil, someRange, 0, NSUserCancelledError) in the NSProgress
1465        /// cancellation handler.
1466        ///
1467        /// The returned NSProgress is used to show progress to the user. If the user cancels the
1468        /// fetch, the extension should stop fetching the item, as it is no longer required.
1469        ///
1470        /// Execution time:
1471        /// ---------------
1472        /// The system will grant enough time to the extension to download the file. The system will interrupt the
1473        /// call if it stops making progress or if download takes an unexpectedly long time. In that case, the system
1474        /// will call `cancel` on the progress. The extension is then expected to quickly call the completion
1475        /// handler.
1476        #[unsafe(method(fetchPartialContentsForItemWithIdentifier:version:request:minimalRange:aligningTo:options:completionHandler:))]
1477        #[unsafe(method_family = none)]
1478        unsafe fn fetchPartialContentsForItemWithIdentifier_version_request_minimalRange_aligningTo_options_completionHandler(
1479            &self,
1480            item_identifier: &NSFileProviderItemIdentifier,
1481            requested_version: &NSFileProviderItemVersion,
1482            request: &NSFileProviderRequest,
1483            requested_range: NSRange,
1484            alignment: NSUInteger,
1485            options: NSFileProviderFetchContentsOptions,
1486            completion_handler: &block2::DynBlock<
1487                dyn Fn(
1488                    *mut NSURL,
1489                    *mut NSFileProviderItem,
1490                    NSRange,
1491                    NSFileProviderMaterializationFlags,
1492                    *mut NSError,
1493                ),
1494            >,
1495        ) -> Retained<NSProgress>;
1496    }
1497);
1498
1499extern_protocol!(
1500    /// [Apple's documentation](https://developer.apple.com/documentation/fileprovider/nsfileproviderexternalvolumehandling?language=objc)
1501    pub unsafe trait NSFileProviderExternalVolumeHandling: NSObjectProtocol {
1502        #[cfg(feature = "block2")]
1503        /// Implement this protocol on your extension's Principal Class in order for the system
1504        /// to ask your extension whether a domain located on an external volume should be connected.
1505        ///
1506        /// Your extension may use this method as an opportunity to check for, and setup if necessary,
1507        /// state to operate the extension. Such as prompting the user to login in your application.
1508        /// When creating domains on external drive, store state related to the domain in the `userInfo` parameter to
1509        /// `-[NSFileProviderDomain initWithDisplayName:userInfo:volumeURL:]`,
1510        /// such as the user's ID, to help your extension identify the domain when connected on other devices. This userInfo will be
1511        /// persisted on the external volume, and provided in the ReplicatedExtension initializer when the drive is connected to a new device.
1512        ///
1513        /// If your extension responds with an NSError, the domain will be in a disconnected state. Non-downloaded files
1514        /// in the domain will not be downloadable, and file edits will not be synced up. The system will display
1515        /// UI to inform the user. Your extension will be able to enumerate this domain in
1516        /// `+[NSFileProviderManager getDomainsWithCompletionHandler:]`, with the
1517        /// `-[NSFileProviderDomain disconnected]` property set as YES.
1518        ///
1519        /// If at a later point, the user has setup the necessary state to service requests for the disconnected external
1520        /// domain, your extension may call `-[NSFileProviderManager reconnectWithCompletionHandler:]`.
1521        ///
1522        /// If your extension does not implement this protocol, domains on external volumes will automatically be
1523        /// connected and instantiated in your extension.
1524        #[unsafe(method(shouldConnectExternalDomainWithCompletionHandler:))]
1525        #[unsafe(method_family = none)]
1526        unsafe fn shouldConnectExternalDomainWithCompletionHandler(
1527            &self,
1528            completion_handler: &block2::DynBlock<dyn Fn(*mut NSError)>,
1529        );
1530    }
1531);