File Provider Delete Enumerated Folders

I noticed when attempting to delete an enumerated folder with didDeleteItems, passing only the top-level folder's ID is not enough to delete the item.

I'm very confused by what you mean here. Why are "you" calling didDeleteItems? That method is how the system tells your extension what the user "did", not how you tell the system what your server did.

As side note here, keep in mind that only passing in the "top level" item is an ENORMOUSLY beneficial performance optimization. In the context of virtually every file system I'm aware of, it is not in fact possible to "delete a directory". More specifically, the act of deleting a full directory hierarchy requires recursively visiting the entire hierarchy, individually deleting each file, then deleting each directory record once the record is empty. Fundamentally, each object has it's own record and there isn't any "shortcut" that would allow "bulk" record removal. That just isn't how file systems work. The optimization here is that the system is aware that you're maintaining a logical hierarchy that may support higher level operations that the underlying (physical) file system does.

Similarly, what you're saying here:

It seems we need to pass all items underneath as well to this function for the folder to be removed.

The system called "didDeleteItems" when it deleted the data "it" had. How the effected YOUR server is entirely up to you. Typically you'd respond by "deleting" your servers data, but there's certainly no requirement that you do so and I can think of many cases where you would NOT do so.

Is there a way around this?

No? As I said, didDeleteItems doesn't actually "do" anything and it's still not clear what you're actually expecting here and why.

The way our application is designed makes it challenging to do this and we would prefer being able to remove the folder by utilizing the item ID only.

Why? Architeturally, I'd expect you file provider to already be maintaining it's own independant state structure tracking everything it's storing, totally independent of the file system. That structure is what it then uses to reconcile changes to and from the server, as well as "exporting" the system/user whenever the system asks for it.

Similalry, this question is very confusing:

If not, how could we obtain the particular items underneath that should be passed in to

the function?

Which items? Are you talking about the nested items that happen to be in the working set?

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware

I noticed when attempting to delete an enumerated folder with didDeleteItems, passing only the top-level folder’s ID is not enough to delete the item. It seems we need to pass all items underneath as well to this function for the folder to be removed.

Yes, that’s correct and can’t really be avoided.

The biggest reason for this is simply because of how the underlying file system actually works. Within the file system itself, every object is tracked with it’s own record each of which needs to be individually deleted. File systems require a directory to be emptied, since that’s the only way (given the way the file system is represented through API) to avoid ending up with a bunch of orphaned files that you can’t actually reference. The file provider architecture is basically just exporting that behavior “up” to your extension. No matter what, “something” is going to have to iterate the entire hierarchy, so the basic task is unavoidable. In theory it could be done with the our “middle” layer, but one of our basic design assumption/requirements is that your layer already has a full picture of it’s entire hierarchy state and needs to be able to reconcile differences between different hierarchy states, so this shouldn’t really be an issue for your implementation. If it is an issue, then I’m not sure file provider is the API you should actually be using.

__
Kevin Elliott
DTS Engineer, CoreOS/Hardware