© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
1b1ed1a
(Get the code!)
Hi again (again),
I just posted an article I'd found to Didier's request (Bug #1249006) with the realization that it actually was something common to both our bug reports.
If you're not of a sensitive nature there's a full on geek argument on technet arguing the pro's and cons of WMI behaviour with disk/volume serial numbers (http://
In essence, it appears that vendors definitely don't work to a common standard. Although it appears that the serial number for a disk (or volume) is encoded as a hex string, it just as likely that it's not. Didier's issue seems to arise from the disk serial number looking like a perfectly convertible hex string but ending up with a binary mess. The same is probably happening for me too.
Can I un-suggest the solution idea's above and re-suggest the following please?
a) Discard entries where there are non-printable characters and return a string to indicate that the encoding was "<unrecognizable>" to highlight the issue.
- because, if there are endian and ascii vs unicode issues it's too hard to guess at the vendor's intentions.
b) Otherwise return the serial number as is
- because, it's equally impossible to tell if a disk serial number is genuinely hex encoded or just abstract;y named in a hex-like way
I appreciate that this will mean some thinking about the field lengths in the server but it feels like it would a more robust approach.
The technet thread suggests that disk serial numbers being hex encoded is a bit of an urban myth...
Regards,
Keith