[Bug 47424] New: DataTransferLength in SCSI_PASS_THROUGH and SCSI_PASS_THROUGH_DIRECT *must* have return value

https://bugs.winehq.org/show_bug.cgi?id=47424

Bug ID: 47424
           Summary: DataTransferLength in SCSI_PASS_THROUGH and
                    SCSI_PASS_THROUGH_DIRECT *must* have return value
           Product: Wine
           Version: 4.0
          Hardware: x86
                OS: Linux
            Status: UNCONFIRMED
          Severity: critical
          Priority: P2
         Component: -unknown
          Assignee: [e-mail]
          Reporter: [e-mail]
      Distribution: ---

I develop Windows software ( fyi: www.isobuster.com )
I have no clue about Linux though advice people to use Wine when needed ( fyi: 
https://www.isobuster.com/linux-mac.php )
I do not use Linux nor wine myself.

So, this is based on user feedback, but I asked to make a log file and based on
that feedback I understand the issue and can report it here:

The user runs IsoBuster 4.4 on Linux Mint 19 Cinnamon using Wine 4.0 (which
simulates Windows 7 (2.6.1.7601)).

FYI:
https://docs.microsoft.com/en-us/windows-hardware/drivers/ddi/content/ntddsc...

When using the SCSI_PASS_THROUGH_DIRECT (or SCSI_PASS_THROUGH) structures I
find that the 'DataTransferLength' field contains '0' after a successful call.
That is not OK, it should contain the amount of bytes that were put in the
buffer during command execution.

To easily reproduce in a debug environment, run IsoBuster in free mode (Get it
here: https://www.isobuster.com/download/ ) and use it on optical media (CD,
DVD, BD).  You will see that no file systems etc. are found.  This is because
IsoBuster internally fails the read commands, and this due to the fact that it
thinks no data was transferred ( DataTransferLength == 0 ).

Older IsoBuster versions did not encounter this issue because they didn't care
about DataTransferLength.  However I found that there are bad behaving (most
likely USB bridge) Windows drivers that return less data than requested (yet
without any error or warning).  For instance a read of 27 * 2352-byte blocks
would succeed but the buffer would only contain some 22 good blocks, and the
rest was nonsense.  I found that especially for read commands I had to double
check DataTransferLength  to make sure the requested data was indeed
transferred.  If not, further retries and/or breaking up the reads then avoids
data corruption.

I'm certain this is a bug and I hope it is fixed soon.  If not I will need to
try and detect Wine and make a work-around, which is less desirable.

Best,
Peter