Misleading/ unprecises error message

[John]

Executing smartctl.exe -l scterc /dev/hdc (on Windows) I get:

smartctl 6.6 2017-11-05 r4594 [x86_64-w64-mingw32-w10-b17134] (sf-6.6-1)
Copyright (C) 2002-17, Bruce Allen, Christian Franke,www.smartmontools.org

SCT Commands not supported

This is unprecise, because it does not state whether SCT is not supported by Windows build, by the current drive or by some hardware used on my system

[John]

Additional info: I tried using it on a SATA drive that is connected via USB - so this might be an issue as well.

[Christian Franke]

These unspecific messages are intentional. It is difficult (and sometimes impossible) to map all corner cases to more specific messages for each platform, for each controller and for each ATA feature check. To prevent misleading messages, I decided 7+ years ago (e.g. r3633) to use unspecific not supported messages.

SCT Commands not supported usually means that the device does not indicate SCT support. But in very rare cases, it may also mean that some layer is unable to transfer the full ATA IDENTIFY information.

[John]

I used the same USB -> SATA adapter on Linux and it worked, so it has nothing to do with the drive or the adapter. I agree that a specific but false error message is even worse than an unspecific message, nevertheless it is quite nasty from a user perspective having to eliminate possible reasons one by one. In this case the reason seems to be either that the windows build does not support it or that the Windows build needs a special driver.

As smartmon uses a drive db anyway this could be extended(?)/used to at least reflect whether the drive itself is capable of feature x (because if that is the case all attempts are doomed to fail). Furthermore if there are platform-specific-limitations, especially on a major platform like windows, it would be good to have these in the faq.

However if this is a hardware specific limitation (e.g. this USB adapter does not work on Windows but other adapters do or a specific host controller on a specific OS is a problem) I understand that this might be hard to debug and denote it in the documentation

[Christian Franke]

I used the same USB -> SATA adapter on Linux and it worked, so it has nothing to do with the drive or the adapter.

IIRC such a difference was never reported before as USB(SCSI) pass-through I/O-controls are usually transparent.

Please be more specific:
Which adapter?
USB Id?
USB bridge (if known)?
Smartctl command lines used on Linux and Windows?

Please provide smartctl -r ioctl,2 -x ... outputs from Linux and Windows using same adapter and drive. Add -d ... if required. Don't past outputs to comments, use attachments instead.