https://bugs.winehq.org/show_bug.cgi?id=47424
--- Comment #6 from Peter peter@smart-projects.net --- Perhaps I'm not understanding the true return value of 'resid' and I cannot test to check but the way I understand it it will return the amount of requested bytes that could *not* be returned (due to a under-run).
So let's assume this hypothetical situation:
An application sends a read10 command of 2 blocks user data, to be read from a data CD. The drive (in case the read10 command succeeds) will return exactly 2*2048 (=4096) bytes.
To do this the application may use a buffer in memory that is bigger, for instance 20480 bytes (space for 10*2048-byte blocks).
The applicatin can set 'DataTransferLength' to 20480 bytes That is perfectly OK and quite common. So 5 times bigger than what is expected to be returned.
Assume the command succeeds but there is a buffer under-run on driver level and for whatever reason the driver only passes through 2048 bytes, not the requested 4096 bytes. IF I understand the use of 'resid' correctly, it will contain a value of 2048 bytes, because 2048 bytes of the requested 4096 bytes could not be transferred.
Suggested code/fix will then set 'DataTransferLength' to 20480-2048 (=18432) bytes. The application however, when it checks 'DataTransferLength' after the command succeeds will think that 9 blocks of data were put in the buffer instead of the requested 2.
Now ... latter statement is *highly unlikely* to happen. An application wants to find value 4096 in 'DataTransferLength' but if the value is higher, will simply not care. Only when the value is lower than 4096 in this case will alarm bells will go off because less data than expected was returned (so a buffer under-run was detected).
I hope this explanation makes sense ? I do not know the exact working of 'resid', so perhaps the fix is perfect. In any case, the now suggested fix *will* work for me and I expect also for other apps than run into this (if at all they run into it).
This is