http://bugs.winehq.org/show_bug.cgi?id=11832
Summary: App scans folders with charts but fails to display them Product: Wine Version: 0.9.56. Platform: PC URL: http://rosepointnav.com/CoastalExplorer/Trial/default.ht m OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: -unknown AssignedTo: wine-bugs@winehq.org ReportedBy: n5470@pinefields.com
As part of normal startup, Coastal Explorer (CE) scans designated (either by default or user choice) specific folders within all drives, building an XML document with descriptions of each chart found. At the end of the process, however, CE announces there are no charts to be found and asks if the user wants to download charts from web sites.
It was found that interrupting the scan process (there is a "Stop" button available) will make charts visible and usable. This is, however, a rather inelegant solution and one which poses problems when using the "Chart Portfolio" tool (e.g., duplication of charts).
http://bugs.winehq.org/show_bug.cgi?id=11832
--- Comment #1 from RBEmerson n5470@pinefields.com 2008-03-04 00:08:38 --- Discussion with the application's author pointed to an area of investigation: the contents of C:\All Users\Application Data\Rose Point Navigation Systems\ and particularly a file with the name form CV_n...n.xml (where n...n is a volume serial number [VSN]). It was the author's opinion that if there were an error in the VSN's or duplication of a VSN, it might cause problems with viewing charts.
I confirmed there was one file, CV_0...0.xml, which appeared to contain expected XML data. Using winecfg, I found that *all* drives (C, X, Y, and Z) had the same VSN: 0. Assigning a new VSN to each drive (1, 2, 3, and 4, respectively) and re-running CE, the scanned charts were displayed as expected. This has been repeated successfully on both the target platform and a second platform.
Recommendation: Wine assign default VSN's to drives, to duplicate this behavior under Windows. Assigning the same VSN, 0, to all drives is likely to cause problems, as shown with CE.
http://bugs.winehq.org/show_bug.cgi?id=11832
Lei Zhang thestig@google.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|App scans folders with |Wine needs to assign drives |charts but fails to display |different serial numbers |them |(affects Coastal Explorer)
--- Comment #2 from Lei Zhang thestig@google.com 2008-03-04 11:46:32 --- So the volume serial numbers can be trivially short, but as long as they are unique, it's ok?
http://bugs.winehq.org/show_bug.cgi?id=11832
--- Comment #3 from RBEmerson n5470@pinefields.com 2008-03-04 14:06:09 --- (In reply to comment #2)
So the volume serial numbers can be trivially short, but as long as they are unique, it's ok?
At least in CE's case, yes. I recommend following existing Window practice / algorithms to create larger, more complex VSN's that, one hopes, will avoid the pitfall of duplicated VSN's. I recommend including all removable media (CD, DVD, USB drive, share) in the VSN assignment process; either use one, if it exists, or create one, if it doesn't.
Background: CE creates one XML file per drive it scans, using the drive's VSN as part of the file name (CV_VSNmsd...VSNlsd.xml). Had the last drive scanned just happened to have some charts in it, the "no charts found" message wouldn't have appeared, only whatever was in the last drive. As it is, the drive had nothing, so the last XML file name, being the same as the others, including filled files, were overwritten by the last, empty file, hence the error message seen.
http://bugs.winehq.org/show_bug.cgi?id=11832
--- Comment #4 from RBEmerson n5470@pinefields.com 2008-03-08 12:39:28 --- No change in this bug under Wine 0.9.57. ~/.wine was deleted and created from scratch with winecfg after installing 0.9.57. C:\ reverted to VSN 0.
http://bugs.winehq.org/show_bug.cgi?id=11832
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download
--- Comment #5 from Austin English austinenglish@gmail.com 2008-06-09 16:40:13 --- Is this still an issue in current (1.0-rc4) or newer wine?
http://bugs.winehq.org/show_bug.cgi?id=11832
--- Comment #6 from Austin English austinenglish@gmail.com 2008-12-17 15:40:17 --- Still present in git.
http://bugs.winehq.org/show_bug.cgi?id=11832
--- Comment #7 from Austin English austinenglish@gmail.com 2010-06-25 21:24:07 --- Still present in git.
http://bugs.winehq.org/show_bug.cgi?id=11832
Dan Kegel dank@kegel.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW CC| |dank@kegel.com Component|-unknown |kernel32 Ever Confirmed|0 |1
--- Comment #8 from Dan Kegel dank@kegel.com 2010-06-26 05:13:11 --- Confirmed by Austin, setting component to kernel32.
Maybe get_filesystem_serial() should return the drive number if no serial file is found.
http://bugs.winehq.org/show_bug.cgi?id=11832
Maya maya.mcleod@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |maya.mcleod@gmail.com
--- Comment #9 from Maya maya.mcleod@gmail.com 2010-08-11 07:26:40 --- If this is the bug where getting a hard drive serial number always shows as 00000000, then it needs to pick up the same serial number that a true windows client would, else applications that use this for copy protection, won't be able to be run in a mixed wine and windows environment.
http://bugs.winehq.org/show_bug.cgi?id=11832
Austin English austinenglish@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |mail@3v1n0.net
--- Comment #10 from Austin English austinenglish@gmail.com 2011-04-25 10:54:49 CDT --- *** Bug 26910 has been marked as a duplicate of this bug. ***
http://bugs.winehq.org/show_bug.cgi?id=11832
Tafel richard.lowe@itchoice.com.na changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |richard.lowe@itchoice.com.n | |a
--- Comment #11 from Tafel richard.lowe@itchoice.com.na 2011-07-26 15:11:42 CDT --- Although you assign unique serial numbers to individual drives their is still a problem. MS uses xxxx-xxxx. If you create the file with that format wine changes it to either a 4 digit.
http://bugs.winehq.org/show_bug.cgi?id=11832
--- Comment #12 from Maya maya.mcleod@gmail.com 2011-07-27 10:35:53 CDT --- I have voted for this bug, but I do not have an option to change the severity.
It is most definitely not Normal, or low severity.
It is preventing users from using Omni Accounts on both Windows and Wine clients on the same network installation.
Our only solution for out clients, has been to use a different emulator.
ie. for users trying to use a mixture of Windows and Wine it is a showstopper bug.
http://bugs.winehq.org/show_bug.cgi?id=11832
Alex Bradbury asb@asbradbury.org changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |asb@asbradbury.org
--- Comment #13 from Alex Bradbury asb@asbradbury.org 2011-07-27 11:38:00 CDT --- (In reply to comment #12)
I have voted for this bug, but I do not have an option to change the severity.
It is most definitely not Normal, or low severity.
By the definitions used for this bugzilla, normal seems correct:
http://bugs.winehq.org/page.cgi?id=fields.html#bug_severity
http://bugs.winehq.org/show_bug.cgi?id=11832
André H. nerv@dawncrow.de changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |nerv@dawncrow.de
--- Comment #14 from André H. nerv@dawncrow.de 2012-11-11 08:03:39 CST --- Just some thoughts: We could use e.g. D.H. Lehmer's 1948 algorithm to generate them. Not sure if this needs to go into wineboot, winecfg, ntdll, or somewhere else. We also need to take care to not destroy old configurations, so we need to respect .windows-serial in the drive root (but still can't do that for z: -> /)
https://bugs.winehq.org/show_bug.cgi?id=11832
Ken Sharp imwellcushtymelike@gmail.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Alias|ChartsNotShown |
--- Comment #15 from Ken Sharp imwellcushtymelike@gmail.com --- Is this still an issue in Wine 1.7.45 or later?
https://bugs.winehq.org/show_bug.cgi?id=11832
super_man@post.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |super_man@post.com
--- Comment #16 from super_man@post.com --- Would think that this bug 17823 which includes a patch, wouldnt need much modification to fix this bug too.
https://bugs.winehq.org/show_bug.cgi?id=11832
winetest@luukku.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian@fds-team.de, | |winetest@luukku.com
https://bugs.winehq.org/show_bug.cgi?id=11832
--- Comment #17 from Sebastian Lackner sebastian@fds-team.de --- (In reply to super_man from comment #16)
Would think that this bug 17823 which includes a patch, wouldnt need much modification to fix this bug too.
The patch from bug 17823 only assigns a serial to drive C (or to be more precise, the drive where Windows is installed). Currently Wine stores them in a ".windows-serial" file located in the corresponding drive directory, but that would not work for Z: or any other drive where the user has no access. Properly fixing this issue for all drives would require to store it somewhere else (for example in the registry, based on dev/inode?).
-
wine-bugs＠winehq.org