com.apple.ignoreowner as a copy source stalls for normal users

[rottegift]

1. Make a dataset with com.apple.ignoreowner=on
2. As a normal user, make a subdirectory in that dataset
3. Create data in the subdirectory as two or more different normal users
4. As one of the normal users in (2), use finder drag-and-drop to copy the subdirectory to another dataset or to an HFS+ filesystem that has ordinary ownership set (i.e., not mounted with noowner).
5. Observe the stall when the finder hits the first fs object that is not owned by the finder user in (4).

Couple observations:

A: The data that you create in (3) will appear to normal users as being owned by them.

However, superuser sees the objects as being owned by the users in (3), depending on who last changed ownership (for example, the user who created the file or directory under the subdirectory).

By contrast, hfs+ noowner mounts show superuser _unknown:_unknown.

B: This also affects rsync, cp, and so forth; they will stall when run as a normal user, but succeed if run as root.

C: drag and drop of the data to an HFS+ filesystem mounted with noowners succeeds (creating _unknown:_unknown ownerships, from root's perspective).

---

The stall is the most important thing to resolve here.

Probably we also should do what HFS+ does and store _unknown:_unknown whenever ownership is set on an object while com.apple.ignoreowner=on.

[rottegift]

If you clone a snapshot of the dataset above and the clone has com.apple.ignoreowner=off, you can finder copy the subdirectory, assuming you have the correct permissions.

[rottegift]

Stalled finder copies from source dataset, when zfs set com.apple.ignoreowner=off sourcedataset: one woke up and started copying, two stayed stalled. Dunno why.

[rottegift]

Cancelling the unstalled copy unstalls a different stalled copy (but not all stalled copies).