So to recap. Win2016 server in our buildbot.
We write to the file and populate the first 2Mb
we set the file to sparse using FSCTL SET-SPARSE
we use SET-INFO and file-end-of-file-info and set the new end of file to 4Mb
we use set-info and file-all-info and update the timestamps
we use get-info/file-all-info and the sparse flag is still set. **
we flush the file (we always destage all dirty pages and flush before
calling qar)
we call qar and sometimes it returns that 0-2Mb is allocated.
sometimes it returns that 0-4Mb is allocated.
In both cases, in ** the sparse flag is still set.
Just looking further down in the trace. A few packets later after the
QAR we re-open the file.
In the SMB2-CREATE response the Sparse flag is still set.
At this point I just consider "sparse flag is just advisory, a hint.
if you expand a sparse file using set-end-of-file the behaviour is
undefined. it can either allocate the new region or it can just leave
it unallocated."
On Fri, Aug 16, 2019 at 12:07 PM ronnie sahlberg
<ronniesahlberg@xxxxxxxxx> wrote:
>
> 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
