FSCTL_MOVE_FILE calls IOCTL_DISK_COPY_DATA

I just ran into a bug in my volume filter where Ntfs calls
IOCTL_DISK_COPY_DATA to copy sectors in order to implement a
FSCTL_MOVE_FILE call. I wasn’t catching this call because I was unaware
that it existed.

What I have found is that FSCTL_MOVE_FILE tends to use
IOCT_DISK_COPY_DATA to move part of a file’s clusters to the destination
and then just reads from the source and writes it to the destination for
the rest of the file.

What I want to do is understand how FSCTL_MOVE_FILE decides to use this
IOCTL rather than reading the source and writing to the destination. I
want to know because it only trips up my driver very rarely and I’m
trying to figure out how to force it to happen. I’ve tried several
FSTCL_MOVE_FILE scenarios and can’t get it to happen. It actually only
happens on some machines during a defrag.

It would be really helpful if someone could give me the basic criteria
Ntfs uses to decide which IOCTL to use.

Thanks,

Jonathan

“Jonathan Ludwig” wrote in message
news:xxxxx@ntfsd…
>I just ran into a bug in my volume filter where Ntfs calls
>IOCTL_DISK_COPY_DATA to copy sectors in order to implement a
>FSCTL_MOVE_FILE call. I wasn’t catching this call because I was unaware
>that it existed.
>
> What I have found is that FSCTL_MOVE_FILE tends to use IOCT_DISK_COPY_DATA
> to move part of a file’s clusters to the destination and then just reads
> from the source and writes it to the destination for the rest of the file.

NTFS tries IOCTL_DISK_COPY_DATA, and when that fails, it will revert to
read/write. If it fails once, it will not be tried again.