A) should result in no new blocks, as it is a move within the same filesystem - only inode info is changing, and should be instantaneous (nearly). Caveat - if data in Folder2 is changed, it will consume snapshot space in the volume.
B) should result in no new blocks, as above - it is a move within the same fileystem and should be quick. Same caveat, if snapshots were taken while it was in the "new" location.
C) WILL consume new blocks, as you are duplicating the data.
Are you saying you first tried to move it, then decided to copy it?
My understanding is that a move within the same filesystem does not incur a true delete/write sequence, as only inodes are being changed, and thus will happen very quickly. This in true in the unix world - I'm pretty sure it is true in the windows world, but I'd have to check. The user saying the initial move would seem to validate this, though your experience seems to invalidate it.... Are these different qtrees? That would count as different filesystems, and would explain the time it is taking (as for the user saying it was instantaneous - well, we know how unreliable users are....)
Any existing snapshots shouldn't affect the move/copy itself - NetApp does what it needs to do in the background. There ARE chances of mass block reclamation impacting performance, though.
I'm rethinking an earlier comment. If you move a file, technically it IS getting deleted from the source location, and thus will show in a snapshot. The question is whether NetApp sees that it was a move, and points those snapshot blocks to the new location, or keeps the blocks in the snapshot and provides new blocks for the destination copy, in which case A) would take new blocks.
I would have to run some tests to be sure. Either way, the status of the snapshots shouldn't affect the user experience in moving data around. Let me know if the source and destination are different qtrees.