[Bug 47424] New: DataTransferLength in SCSI_PASS_THROUGH and SCSI_PASS_THROUGH_DIRECT *must* have return value
wine-bugs at winehq.org
wine-bugs at winehq.org
Thu Jun 27 08:27:25 CDT 2019
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: wine-bugs at winehq.org
Reporter: peter at smart-projects.net
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/ntddscsi/ns-ntddscsi-_scsi_pass_through_direct
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
--
Do not reply to this email, post in Bugzilla using the
above URL to reply.
You are receiving this mail because:
You are watching all bug changes.
More information about the wine-bugs
mailing list