http://bugs.winehq.org/show_bug.cgi?id=29426
Bug #: 29426 Summary: UDF support: VOLUME_GetSuperblockSerial invalid for some volume types Product: Wine Version: unspecified Platform: All OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: kernel32 AssignedTo: wine-bugs@winehq.org ReportedBy: winehq.org@mcfang.com Classification: Unclassified
VOLUME_GetSuperblockSerial returns an incorrect serial for certain UDF volumes.
Volume types affected: * ISO9660+UDF for all revisions: Serial displays as '0104-0001' * UDF revision 2.50/2.60: Serial displays as '0000-0000'
Serial is correct for standalone UDF revisions 1.02/1.50/2.00/2.01
Test Case: Run 'wine cmd' to open the command line and observe the output of the `vol` command. Output differs from `vol` run on a native windows system for the above volume types.
History: UDF support was introduced as a patch for bug #26273 http://bugs.winehq.org/show_bug.cgi?id=26273 and is hardcoded to use the 257th sector (Address 526336) for serial calculation.
The actual sector used for serial calculations depends on the UDF revision and volume type. I suspect the sector may be coded somewhere in the UDF Specifications, and if that is the case then it should be a better solution than hardcoding.
Serial calculations: * Sector 257 for UDF revisions 1.02/1.50/2.00/2.01 * Sector 260 for ISO9660+UDF revisions 1.02/1.50/2.00/2.01 * Sector 320 for UDF revisions 2.50/2.60 with or without ISO9660
http://bugs.winehq.org/show_bug.cgi?id=29426
Vitaliy Margolen vitaliy-bugzilla@kievinfo.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Platform|All |Other
--- Comment #1 from Vitaliy Margolen vitaliy-bugzilla@kievinfo.com 2011-12-23 13:36:12 CST --- Could you point to spec describing which blocks the volume serial number is located?
http://bugs.winehq.org/show_bug.cgi?id=29426
mcfang winehq.org@mcfang.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |cerebro.alexiel@gmail.com
--- Comment #2 from mcfang winehq.org@mcfang.com 2011-12-23 22:34:09 CST --- (In reply to comment #1)
Could you point to spec describing which blocks the volume serial number is located?
I could not decipher the UDF spec to find which sector was being used for serial calculations so I hope that someone with some experience with UDF or ECMA-167 can shed some light.
The sectors I gave in the bug report are based on manual investigation of the volumes.
http://bugs.winehq.org/show_bug.cgi?id=29426
--- Comment #3 from mcfang winehq.org@mcfang.com 2011-12-23 22:34:32 CST --- (In reply to comment #1)
Could you point to spec describing which blocks the volume serial number is located?
I could not decipher the UDF spec to find which sector was being used for serial calculations so I hope that someone with some experience with UDF or ECMA-167 can shed some light.
The sectors I gave in the bug report are based on manual investigation of the volumes.
http://bugs.winehq.org/show_bug.cgi?id=29426
--- Comment #4 from Dmitry Timoshkov dmitry@baikal.ru 2011-12-24 00:36:40 CST --- Please specify 'wine --version' in the Version field above.
http://bugs.winehq.org/show_bug.cgi?id=29426
mcfang winehq.org@mcfang.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Version|unspecified |1.3.35
http://bugs.winehq.org/show_bug.cgi?id=29426
--- Comment #5 from Alex cerebro.alexiel@gmail.com 2011-12-24 04:38:39 CST --- (In reply to comment #1)
Could you point to spec describing which blocks the volume serial number is located?
I'm the author of the patch "kernel32: Add UDF support" (http://source.winehq.org/git/wine.git/commitdiff/73f4e23938142225efdc233f9db...)
I read the spec and the volume serial is not part of it. In fact, Windows uses its own algorithm depending on the filesystem of the volume.
See http://social.msdn.microsoft.com/Forums/en-US/windowsopticalplatform/thread/... Quoting the author : "This serial number is NOT part of the file system on the disc and is NOT located on the source disc AT ALL. It is entirely generated by Windows."
See also the code used by wine : http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/kernel32/volume.c#l569
To find which sector was used by Microsoft : - I made an ISO of my Sims3 DVD (a retailer/genuine one) - I got the serial of it from a (VirtualBox'ed and genuine) XP by mounting the ISO file - I simply wrote a for loop and found it was the 257th sector with bytes reversed
Note that it was the only UDF DVD I had (and still have).
If you found that this sector depends on the UDF revision, the code must be changed.
Either you feel ready to write a patch (I can review it if you want) or not and in this case, I can write it for you.
http://bugs.winehq.org/show_bug.cgi?id=29426
--- Comment #6 from mcfang winehq.org@mcfang.com 2011-12-28 21:00:05 CST --- Thanks Alex!
I am also aware that the 'serial' is not in the spec, but the specific sector used by Microsoft appears to be consistent across different UDF revisions which is why I believe it can be mapped by understanding the UDF spec. This would also be more robust than guessing the sector based on the UDF revision.
I'm guessing the sector used for the serial is related to the start of the data partition. The Partition Descriptor might hold the key: it appears to give the correct sector for all volume types except in UDF 2.50/2.60 where it gives 288 instead of 320.
http://bugs.winehq.org/show_bug.cgi?id=29426
--- Comment #7 from Alex cerebro.alexiel@gmail.com 2012-07-22 13:14:49 CDT --- Created attachment 41104 --> http://bugs.winehq.org/attachment.cgi?id=41104 A simple program to compare the sector used to compute the serial and the partition starting location
I finally managed to write a program that displays : + the sector used to compute the serial from GetVolumeInformation + and the field 'partition starting location' of the Partition Descriptor
You can compile it with mingw (i686-w64-mingw32-gcc on my computer) And run it, on Windows, with a DVD drive in, from the command line.
The syntax is : <nameOfTheExe> <DosDriveLetter> the last one is optional and will default to F
So give it a try with a maximum of UDF DVD and give us the results
http://bugs.winehq.org/show_bug.cgi?id=29426
Alex cerebro.alexiel@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Attachment #41104|0 |1 is obsolete| |
--- Comment #8 from Alex cerebro.alexiel@gmail.com 2012-12-02 06:14:21 CST --- Created attachment 42691 --> http://bugs.winehq.org/attachment.cgi?id=42691 Use the FSD sector to compute the UDF serial
In the past weeks, I did several tests and found several things :
+ windows does not compute the serial on demand but when the media is inserted. + windows does a light check : it doesn't check TEA01 presence, doesn't read every file entry but looks for the Autorun file... + the sector used to compute the serial is not the partition starting location nor dependant of the UDF revision but is the location of the FSD (file set descriptor) location.
I'm pretty convinced of what I found but I'd like you, mcfang, to test my patch and report here if it matches windows behavior.
The simplest way to test the serial is to use cmd (and wine cmd), then typing e: (or the appropriate letter) to change the working directory and executing the dir command.
Thanks for your help
http://bugs.winehq.org/show_bug.cgi?id=29426
Bruno Jesus 00cpxxx@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |00cpxxx@gmail.com
--- Comment #9 from Bruno Jesus 00cpxxx@gmail.com 2012-12-11 17:24:21 CST --- A patch related to this bug was commited: http://source.winehq.org/git/wine.git/?a=commit;h=d0001e357a4e054a883a02cf97...
http://bugs.winehq.org/show_bug.cgi?id=29426
--- Comment #10 from mcfang winehq.org@mcfang.com 2012-12-18 02:39:32 CST --- Alex, I tested your patch and it gives the expected result for all volume types I tried.
Great work, credit to you.
http://bugs.winehq.org/show_bug.cgi?id=29426
--- Comment #11 from Alex cerebro.alexiel@gmail.com 2012-12-18 02:50:23 CST --- Glad to see I was right. You can now change the status of this bug to RESOLVED. AJ will close it Friday for wine v1.5.20 .. if we're still alive ;)
http://bugs.winehq.org/show_bug.cgi?id=29426
mcfang winehq.org@mcfang.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |RESOLVED Resolution| |FIXED
--- Comment #12 from mcfang winehq.org@mcfang.com 2012-12-18 02:51:59 CST --- Fixed with submitted patch
http://bugs.winehq.org/show_bug.cgi?id=29426
Nikolay Sivov bunglehead@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed by SHA1| |d0001e357a4e054a883a02cf97b | |e02db90310088
http://bugs.winehq.org/show_bug.cgi?id=29426
Alexandre Julliard julliard@winehq.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED
--- Comment #13 from Alexandre Julliard julliard@winehq.org 2012-12-21 13:29:17 CST --- Closing bugs fixed in 1.5.20.