This bug was raised by David Howells on the upstream Samba / cifs.ko mailing lists. Tom Talpey and Ronnie clarified the expected behaviour: On 5/23/2024 2:36 AM, David Howells wrote: > ronnie sahlberg <ronniesahlberg@gmail.com> wrote: > >>> The problem is that it essentially renders SEEK_DATA/SEEK_HOLE unusable for >>> applications on cifs. If there's more than one extent above the starting >>> position, they'll fail with EIO. The only way to do it is to provide for a >>> sufficiently large buffer to accommodate however many extents that there are >>> (and there could be millions, in theory) in order to get just the first one. >> >> Wait, I didn't read all the text in the initial posts correctly. >> Do you mean if you ask for "max x bytes of response, enough for n >> entries" then if there >> are > n entries on the server you get nothing back? >> >> I am pretty sure Windows will return as many entries as fits in the >> reponse out-data-size >> nad some error code. >> But you are saying that instead of returning a truncated out-blob that > If OutputBufferSize < ((OutputBufferIndex + 1) * sizeof(FILE_ALLOCATED_RANGE_BUFFER)) then: > > Set Status to STATUS_BUFFER_OVERFLOW. >> samba will return nothing? > > It returns a STATUS_BUFFER_TOO_SMALL error if there's more than one extent > record to return. Yeah, I think this is a Samba server issue. Ronnie is right that it should return a partial response and a STATUS_BUFFER_OVERFLOW error indicating that it's partial. It's not supposed to return STATUS_BUFFER_TOO_SMALL unless the entire buffer is less than one entry. MS-FSA section 2.5.10.22 https://learn.microsoft.com/en-us/openspecs/windows_protocols/ms-fsa/385dec98-90fe-477f-9789-20a47a7b8467 Tom.
This bug was referenced in samba master: 5e278a52646a48e3671270e5b57ec5b852f9fb4b
Created attachment 18419 [details] cherry-picked fix for 4.19-test
Created attachment 18420 [details] cherry-picked fix for 4.20-test
Created attachment 18421 [details] cherry-picked fix for 4.21-test
Comment on attachment 18419 [details] cherry-picked fix for 4.19-test Think if it isn't much trouble we should keep the torture test to ease verification and prevent regressions
Comment on attachment 18420 [details] cherry-picked fix for 4.20-test same comment as 4.19 patch
Comment on attachment 18421 [details] cherry-picked fix for 4.21-test as the others but in this case the missing torture function is in this release so no need to drop the test
Created attachment 18423 [details] backport for 4.19/4.20 test has been modified to use the existing torture_assert_u64 fn. I think for the test this is sufficient
Created attachment 18424 [details] backported patch for 4.21
-> jule for backporting 4.19, 4.20, 4.21 (not sure if all are still supported)
Pushed to autobuild-v4-{21,20,19}-test. Yes, they are all still supported.
This bug was referenced in samba v4-21-test: 10dddd55152efbe578b01b25c8bb58a9ea7abc3b
This bug was referenced in samba v4-20-test: 72aa92c67d861a676377dd13397d797394178e90
autobuild-v4-19-test failed for samba-h5l-build during make. Reassigning to Noel.
This bug was referenced in samba v4-21-test: b2ce6308c1927d844bbae519f0aa1c9ef446001c
This bug was referenced in samba v4-19-test: 1602d847354f0b72057ff3af1f9002e7c26bc494
This bug was referenced in samba v4-21-stable (Release samba-4.21.0): 10dddd55152efbe578b01b25c8bb58a9ea7abc3b b2ce6308c1927d844bbae519f0aa1c9ef446001c
This bug was referenced in samba v4-20-test: 9e2c58c7d39737d4eae091a518bdcc21837b7f35
Closing out bug report. Thanks!
This bug was referenced in samba v4-20-stable (Release samba-4.20.5): 72aa92c67d861a676377dd13397d797394178e90 9e2c58c7d39737d4eae091a518bdcc21837b7f35
This bug was referenced in samba v4-19-stable (Release samba-4.19.9): 1602d847354f0b72057ff3af1f9002e7c26bc494