On Fri, Aug 16, 2019 at 1:48 AM David Disseldorp <ddiss@xxxxxxx> wrote:
>
> Hi Ronnie,
>
> Is the file flagged sparse (FSCTL_SET_SPARSE()) prior to the QAR
> request?
Yes. The file is written to, the first 2MB.
Then FSCTL_SET_SPARSE is called to make it sparse.
Then there is a SET-INFO SET_END_OF_FILE to expand the file to 4Mb.
there are a few other commands
Then there is a GET-INFO / FILE_ALL_INFO and the sparse flag is still set
then a QUERY_ALLOCATED_RANGES which returns a single region from 0 to 4Mb.
The whole behavior is really odd.
I am happy to mail you the wireshark traces for this. Can I do that?
Just so you can look at them and confirm I am not crazy :-)
I cant send them to the list because they are 5Mb each and it is rude
to send such big attachments to a mailinglist.
> When implementing the Samba server-side I tried to match
> Windows/spec behaviour with:
>
> 702 if (!fsp->is_sparse) {
> 703 struct file_alloced_range_buf qar_buf;
> 704
> 705 /* file is non-sparse, claim file_off->max_off is allocated */
> 706 qar_buf.file_off = qar_req.buf.file_off;
> 707 /* + 1 to convert maximum offset back to length */
> 708 qar_buf.len = max_off - qar_req.buf.file_off + 1;
> 709
> 710 status = fsctl_qar_buf_push(mem_ctx, &qar_buf, &qar_array_blob);
> 711 } else {
> 712 status = fsctl_qar_seek_fill(mem_ctx, fsp, qar_req.buf.file_off,
> 713 max_off, &qar_array_blob);
> 714 }
>
> ...in which case you should see similar test results against Samba. This
> also excersized via the ioctl_sparse_qar* smbtorture tests.
>
> Cheers, David
