Comment 2 for bug 1247530

Yes, "pinning" files should be a convergence behavior. Otherwise there may be scenarios in which "pinning" presents an obstacle to data safety.
With "pinning" as a convergence behavior, we get a few advantages:
    1) the Shuffling behavior works properly
    2) we view pinning as something to be achieved over a period of time, resuming after reboots etc.

Transferring pinned files should be done as quickly as I/O allows. Users will expect "pinning" to work as quickly as copying files to another drive usually takes. It might still be a long-running operation involving the transfer of terabytes of assets, which is why viewing it as a convergent, continuing process is a good idea.

Something that *might* be possible is Shuffling may interfere with "pinning" in essence:
    Should we prioritize a specific level of data safety over data usefulness?
If the user needs to "pin" a project-full of data to a drive for transfer, and shuffling interferes with the "pinning" process, this could stop a partner from getting the assets needed to begin working. I'm not sure such a scenario is possible. It could be prevented by marking such drives as "transient" to indicate they shouldn't be used for shuffling and "pinning" takes precedence.

In any case, the user should be kept apprised of the status of all incomplete "pinning" processes and informed when the "pinning" process has completed for a specified group of files. The dmedia indicator could list incomplete(due to Shuffling) and in-progress "pinning" groups. And a notification should announce when a "pinning" group has completed. Likewise a notification should appear when a "pinned" group becomes incomplete due to shuffling, so the user doesn't mistakenly send an incomplete set of files.