[Bug 34406] New: regression: Finale Notepad 2012 doesn't copy/create user files on program start
http://bugs.winehq.org/show_bug.cgi?id=34406 Bug #: 34406 Summary: regression: Finale Notepad 2012 doesn't copy/create user files on program start Product: Wine Version: 1.7.0 Platform: x86 OS/Version: Linux Status: UNCONFIRMED Severity: normal Priority: P2 Component: advapi32 AssignedTo: wine-bugs(a)winehq.org ReportedBy: s_chriscollins(a)hotmail.com Classification: Unclassified Program: Finale NotePad 2012 (free download) Download URL: http://www.finalemusic.com/products/finale-notepad/ Commit causing regression: 5851032d07c321f2c050187115cfd8e21b5f3f49 (advapi: Implement SetNamedSecurityInfoW on top of SetSecurityInfo.) Reproducing the Bug: 1) Download and install Finale NotePad 2012. 2) Run the Finale Notepad 2012 application. 3) Click "OK" or "Continue" on all the dialogs, and then you'll get to a registration dialog. Click "Remind Me Later". Result: Finale throws an error: "Finale NotePad cannot start the Wizard because a necessary data file (Maestro Font Default.FTM) could not be found." Expected result: NotePad should bring up the new song wizard, which it does correctly using Wine 1.4 and all versions leading up to the commit listed above. Here's what appears to be happening: When installing Finale NotePad, default user files are copied to "drive_c/users/Public/Application Data/MakeMusic". When running the NotePad application for the first time after installation, files are copied from this public location to the current user at "drive_c/users/[username]/Application Data/MakeMusic", and some additional configuration files are created in this same location. After the regression, these user-specific files are never copied/created, causing NotePad to throw the error. Once these files are created, perhaps by an earlier version of Wine, NotePad will run even in newer versions of Wine. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 S. Christian Collins <s_chriscollins(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Regression SHA1| |5851032d07c321f2c050187115c | |fd8e21b5f3f49 -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 S. Christian Collins <s_chriscollins(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |regression -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #1 from S. Christian Collins <s_chriscollins(a)hotmail.com> 2013-08-31 13:02:15 CDT --- I should also mention, I tested this with the latest git as of yesterday (8/30/2013) and the bug is still present. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 Bruno Jesus <00cpxxx(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |download URL| |http://www.finalemusic.com/ | |products/finale-notepad/ -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 S. Christian Collins <s_chriscollins(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |julliard(a)winehq.org -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 Erich Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |erich.e.hoover(a)gmail.com --- Comment #2 from Erich Hoover <erich.e.hoover(a)gmail.com> 2013-09-20 19:22:22 CDT --- I just noticed this on my regression list and took a moment to take a quick look at it before heading out the door. It appears that the application is changing the access to the folder to be write-only with its SetNamedSecurityInfo call, so that's why the copy doesn't occur. It's possible that NtSetSecurityObject isn't properly parsing the DACL, as there doesn't appear to be anything wrong with the SetNamedSecurityInfo or SetSecurityInfo implementation (with regard to what this application wants). -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #3 from Erich Hoover <erich.e.hoover(a)gmail.com> 2013-11-06 15:56:03 CST --- (In reply to comment #1)
I should also mention, I tested this with the latest git as of yesterday (8/30/2013) and the bug is still present.
I'm finally getting around to digging into this a little bit, would you mind seeing what happens permissions-wise on Windows for the user's "Application Data/MakeMusic" folder? I suspect that it's setting world-writable permissions (exclusively) and inheriting permissions from the parent folder that allows the user to continue to read the files. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #4 from S. Christian Collins <s_chriscollins(a)hotmail.com> 2013-11-11 12:53:40 CST --- (In reply to comment #3)
I'm finally getting around to digging into this a little bit, would you mind seeing what happens permissions-wise on Windows for the user's "Application Data/MakeMusic" folder? I suspect that it's setting world-writable permissions (exclusively) and inheriting permissions from the parent folder that allows the user to continue to read the files.
That is what it appears to be doing on Windows. The user's MakeMusic folder and subfolders have the following permissions: User: Everyone Basic Permissions: Write, Special permissions Advanced Permissions: Create files/ write data Create folders/ append data Write attributes Write extended attributes Read permissions User: SYSTEM / Administrators / Owner Basic Permissions: Full control -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #5 from Erich Hoover <erich.e.hoover(a)gmail.com> 2013-11-11 12:56:30 CST --- (In reply to comment #4)
... That is what it appears to be doing on Windows. The user's MakeMusic folder and subfolders have the following permissions: User: Everyone Basic Permissions: Write, Special permissions Advanced Permissions: Create files/ write data Create folders/ append data Write attributes Write extended attributes Read permissions
User: SYSTEM / Administrators / Owner Basic Permissions: Full control
What does it say under the "Inherited From" column? -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #6 from S. Christian Collins <s_chriscollins(a)hotmail.com> 2013-11-11 13:04:57 CST --- (In reply to comment #5)
What does it say under the "Inherited From" column?
For "Everyone", it is inherited from "None". For The other three (SYSTEM, Administrators, chris) it is inherited from "C:\Users\chris\". -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #7 from Erich Hoover <erich.e.hoover(a)gmail.com> 2013-11-11 17:38:22 CST --- (In reply to comment #6)
(In reply to comment #5)
What does it say under the "Inherited From" column?
For "Everyone", it is inherited from "None". For The other three (SYSTEM, Administrators, chris) it is inherited from "C:\Users\chris\".
Hmmm, the only permissions I see it setting are 0x40000000 (GENERIC_WRITE)... -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #8 from Erich Hoover <erich.e.hoover(a)gmail.com> 2013-11-25 18:45:07 CST --- (In reply to comment #7)
(In reply to comment #6)
(In reply to comment #5)
What does it say under the "Inherited From" column?
For "Everyone", it is inherited from "None". For The other three (SYSTEM, Administrators, chris) it is inherited from "C:\Users\chris\".
Hmmm, the only permissions I see it setting are 0x40000000 (GENERIC_WRITE)...
According to this article : http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx it appears that write permission on a folder implies read permissions. I'm not entirely sure how we need to handle that internally, but that probably explains what's going wrong here. I can hopefully write a test case for this pretty easily, so that should help narrow down the solution space. -- Configure bugmail: http://bugs.winehq.org/userprefs.cgi?tab=email 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #9 from Erich Hoover <erich.e.hoover(a)gmail.com> --- I'm having trouble with GENERIC_WRITE implying read (I can't find a test that reproduces this possible behavior). So, I created a small program to list out all the permissions for your folder: https://dl.dropboxusercontent.com/u/195059/wine/test.exe https://dl.dropboxusercontent.com/u/195059/wine/test.c (source) So, if you could run (on Windows with the actual folder): test.exe "C:\users\Public\Application Data\MakeMusic" and then send me the output I'd appreciate it. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #10 from Dmitry Timoshkov <dmitry(a)baikal.ru> --- (In reply to comment #8)
According to this article : http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
it appears that write permission on a folder implies read permissions.
I can't find that assumption in that article: Permissions for Files and Folders: List Folder/ Read Data: List Folder allows or denies viewing file names and subfolder names in the folder. List Folder only affects the contents of that folder; it does not affect whether the folder you are setting the permission on will be listed. (Applies to folders only.) Read Data allows or denies viewing data in files. (Applies to files only.) Create Files/ Write Data: Create Files allows or denies creating files in the folder. (Applies to folders only.) Write Data allows or denies making changes to the file and overwriting existing content. (Applies to files only.) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #11 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- I ran test.exe in both Windows 8 and Windows XP. The program crashed in XP, so I only have the Windows 8 results. Windows 8 ("C:\ProgramData\MakeMusic"): sid: S-1-1-0, mask: 0x120116, flags: 0 sid: S-1-5-18, mask: 0x1f01ff, flags: 13 sid: S-1-5-32-544, mask: 0x1f01ff, flags: 13 sid: S-1-3-0, mask: 0x10000000, flags: 1b sid: S-1-5-32-545, mask: 0x1200a9, flags: 13 sid: S-1-5-32-545, mask: 0x116, flags: 12 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 Erich Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #12 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to comment #10)
(In reply to comment #8)
According to this article : http://technet.microsoft.com/en-us/library/cc783530%28v=ws.10%29.aspx
it appears that write permission on a folder implies read permissions.
I can't find that assumption in that article: ...
In the table it shows that when Write permission is granted (column) then special "Read Permissions" are achieved (row). I'm not sure this is actually the case after doing some testing. (In reply to comment #11)
... sid: S-1-1-0, mask: 0x120116, flags: 0 sid: S-1-5-18, mask: 0x1f01ff, flags: 13 sid: S-1-5-32-544, mask: 0x1f01ff, flags: 13 sid: S-1-3-0, mask: 0x10000000, flags: 1b sid: S-1-5-32-545, mask: 0x1200a9, flags: 13 sid: S-1-5-32-545, mask: 0x116, flags: 12
Excellent, that confirms my original theory then - it is the inherited permissions that allow this folder to be read. So, that would make this somewhat related to Bug #33576, the fix is the same - but that bug is about specific permissions not being recalled rather than the permissions being inherited from the parent folder. I'm currently maintaining a set of patches for this as part of the Silverlight/PlayReady work I've been doing, so it'd be worth applying those patches and giving that a try: https://github.com/compholio/wine-compholio-daily/tree/master/patches/02-ACL... -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #13 from Ken Thomases <ken(a)codeweavers.com> --- (In reply to comment #12)
In the table it shows that when Write permission is granted (column) then special "Read Permissions" are achieved (row).
"Read Permissions" doesn't mean permission to read the file contents. It means permission to read the permissions. That is, a program with Write access can query the file's permissions, too. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 Erich Hoover <erich.e.hoover(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Depends on| |33576 --- Comment #14 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to comment #12)
... Excellent, that confirms my original theory then - it is the inherited permissions that allow this folder to be read. So, that would make this somewhat related to Bug #33576, the fix is the same - but that bug is about specific permissions not being recalled rather than the permissions being inherited from the parent folder. I'm currently maintaining a set of patches for this as part of the Silverlight/PlayReady work I've been doing, so it'd be worth applying those patches and giving that a try: https://github.com/compholio/wine-compholio-daily/tree/master/patches/02- ACL_Extended_Attributes
Note: I just tested this and these patches, on their own, are insufficient to solve the problem for two reasons: 1) The user-specific "Application Data" does not currently have any inheritable permissions set. 2) It is additionally necessary for SetSecurityAttributes to look at the inheritable attributes (I have not implemented this yet). I'll take a look at implementing these things as soon as I can. (In reply to comment #13)
(In reply to comment #12)
In the table it shows that when Write permission is granted (column) then special "Read Permissions" are achieved (row).
"Read Permissions" doesn't mean permission to read the file contents. It means permission to read the permissions. That is, a program with Write access can query the file's permissions, too.
That makes a lot more sense :) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 Dmitry Timoshkov <dmitry(a)baikal.ru> changed: What |Removed |Added ---------------------------------------------------------------------------- Summary|regression: Finale Notepad |Finale Notepad 2012 doesn't |2012 doesn't copy/create |copy/create user files on |user files on program start |program start -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #15 from Erich Hoover <erich.e.hoover(a)gmail.com> --- It's taken me quite a while to rewrite my patches to handle this case, but I've posted an updated version that should fix your issue: https://github.com/compholio/wine-compholio-daily/tree/master/patches/02-ACL... These patches implement the following changes: 1) File ACLs are stored in Extended Filesystem Attributes on the system 2) When creating a directory with security attributes attached then attributes are inherited from parent folders 3) When setting the attributes on a file (or directory) without the PROTECTED_DACL_SECURITY_INFORMATION flag then attributes are inherited from parent folders 4) The creation of user shell folders now has inheritable ACLs for the user and administrator Patch installation instructions: 1) Apply the patches (patch -p1 < patch-to-apply.path) 2) Update the configure script (autoreconf) 3) Run the updated configure script (./configure) 4) Compile and install the updated Wine (make && sudo make install) Note that your file system and kernel must support Extended Filesystem Attributes and the development library headers must be installed. If you give me more details about your system (distro, version, etc.) I can help you if getting things working poses a problem. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #16 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- I'm ready to test this out. I'm using Kubuntu 12.04 with kernel 3.5.0-45-generic. Do I need to add the "user_xattr" flag to the fstab entry for my home folder for this to work? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #17 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to comment #16)
I'm ready to test this out. I'm using Kubuntu 12.04 with kernel 3.5.0-45-generic. Do I need to add the "user_xattr" flag to the fstab entry for my home folder for this to work?
If you are using ext3 then yes, if you are using ext4 then extended attributes are enabled by default. You can use the following to test whether extended attributes are enabled: touch ~/.xattr_test && setfattr -n 'user.testAttr' -v 'attribute value' ~/.xattr_test &> /dev/null; getfattr ~/.xattr_test 2>&1 | grep -q user.testAttr && echo 'It works!' || echo 'No extended attribute support!'; rm ~/.xattr_test &> /dev/null -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #18 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- I can confirm that the patches do indeed resolve this bug. Cheers, mate! :) -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #19 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to comment #18)
I can confirm that the patches do indeed resolve this bug. Cheers, mate! :)
Great! I need to wait to submit these until I have some other patches accepted, but these patches are pretty high on my priority list after that. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #20 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- What is the current status of these patches? -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #21 from Erich Hoover <erich.e.hoover(a)gmail.com> --- (In reply to S. Christian Collins from comment #20)
What is the current status of these patches?
They went through a pretty major revision recently ( still available at https://github.com/compholio/wine-compholio-daily/tree/master/patches/02-ACL... ) and, after a little more testing and small cleanup, should be ready for submission. However, these are complicated changes to the wineserver and I need to finish getting my other wineserver changes upstream first (support for SIO_ADDRESS_LIST_CHANGE). I've been working on getting these changes in for about a year now and I've only just recently got the first patch accepted, so I'm not about to switch gears and move over to the ACL patches until the SIO_ADDRESS_LIST_CHANGE patches are upstream. -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks| |30489 -- 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.
http://bugs.winehq.org/show_bug.cgi?id=34406 Anastasius Focht <focht(a)gmx.net> changed: What |Removed |Added ---------------------------------------------------------------------------- Blocks|30489 | -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34406 Terran <reid(a)halfcadence.net> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |reid(a)halfcadence.net --- Comment #22 from Terran <reid(a)halfcadence.net> --- I can confirm that I'm able to start Finale 2012 and open/create files properly using a build with these patches applied. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34406 Sebastian Lackner <sebastian(a)fds-team.de> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |sebastian(a)fds-team.de --- Comment #23 from Sebastian Lackner <sebastian(a)fds-team.de> --- Just to make sure, that everyone looking into this bug actually finds the latest version of our patches - they are available at: https://github.com/wine-compholio/wine-staging/tree/master/patches/ntdll-DOS... https://github.com/wine-compholio/wine-staging/tree/master/patches/server-St... https://github.com/wine-compholio/wine-staging/tree/master/patches/server-In... Please note that the patches depend on each other, dependency information and other metadata can be found in the "definition" file in each directory. Our repository contains also further ACL related patches, but the three mentioned above should be sufficient to fix the issue described here. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34406 Piotr Caban <piotr.caban(a)gmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |piotr.caban(a)gmail.com --- Comment #24 from Piotr Caban <piotr.caban(a)gmail.com> --- It works for me now. Please retest. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34406 --- Comment #25 from Erich E. Hoover <erich.e.hoover(a)wine-staging.com> --- (In reply to Piotr Caban from comment #24)
It works for me now. Please retest.
S. Christian Collins: Have you had a chance to retest with unpatched Wine? It would be nice to confirm that this issue is resolved. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34406 S. Christian Collins <s_chriscollins(a)hotmail.com> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #26 from S. Christian Collins <s_chriscollins(a)hotmail.com> --- I can confirm that this bug has indeed been fixed! Tested using Wine 1.7.45. -- 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.
https://bugs.winehq.org/show_bug.cgi?id=34406 Alexandre Julliard <julliard(a)winehq.org> changed: What |Removed |Added ---------------------------------------------------------------------------- Status|RESOLVED |CLOSED --- Comment #27 from Alexandre Julliard <julliard(a)winehq.org> --- Closing bugs fixed in 1.7.46. -- 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.
participants (1)
-
wine-bugs＠winehq.org