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);