ZFS recv gets confused about receive_resume_token when -F is used.
1) zfs recv -s is first used, and for whatever reason, is aborted to leave a receive_resume_token
2) decide to sent it again, using -F to "rollback" and send the whole thing (don't use receive_resume_token)
3) completed dataset now has receive_resume_token, and zfs recv -A does not remove it.
# zfs send -v BOOM/two@send | zfs recv -s BOOM/halfsent ^C # zfs get receive_resume_token BOOM/halfsent BOOM/halfsent receive_resume_token 1-a743d9fea-etc (If you try to send the whole thing again, it will helpfully tell you to use -F) # zfs send -v BOOM/two@send | ./cmd.sh zfs recv -F BOOM/halfsent # # zfs get receive_resume_token BOOM/halfsent BOOM/halfsent receive_resume_token 1-a743d9fea-etc # zfs recv -A BOOM/halfsent 'BOOM/halfsent' does not have any resumable receive state to abort
I am unsure if "-F" should (silently) remove the receive_resume_token, or if it is "zfs recv -A" that should be fixed to handle the case where -F was used.
ps. Slightly misleading error message if you accidentally include the @snapshot part of the name to -A:
# zfs recv -A BOOM/halfsent@send cannot open 'BOOM/halfsent@send': trailing slash in name