On Thu, 23 May 2024 at 16:21, David Howells <dhowells@xxxxxxxxxx> wrote: > > ronnie sahlberg <ronniesahlberg@xxxxxxxxx> wrote: > > > On Thu, 23 May 2024 at 14:54, David Disseldorp <ddiss@xxxxxxxxx> wrote: > > It might be best to just ignore tests that fail in this area. And just > > accept that some things, at best, is a best-effort approximation. > > (as long as dataloss does not happen, of course. That is never acceptable) > > At the end of the day it is a lot of guesswork and trying to fit a > > square peg (unpredictable ntfs behavior) into a round hole (linux vfs > > api). > > 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 samba will return nothing? I will test this tomorrow on a win16 server. > > David >
