http://bugs.winehq.org/show_bug.cgi?id=10282
--- Comment #9 from Szabolcs Szakacsits szaka@ntfs-3g.org 2007-11-05 04:11:30 --- (In reply to comment #8)
(In reply to comment #7)
No need to emulate anything because when an application does such mmap system call then the driver returns ENODEV which can be easily handled. See mmap(2).
It can't really be handled, all we can do is report the failure to the app,
This is exactly what I have meant. You should report this to the app instead of crashing.
which in most cases will crash since the app doesn't expect it.
That's a problem in the app.
Crash is not a nice way to terminate applications when it would be possible to handle such errors more elegantly and providing useful information to the user to fix his problem without any developer involvment.
Please also realize that mmap(2) has absolutely nothing to do with this bug report.
Judging from the traces in bug 10255 the problem is a failure to map code as executable, so it looks to me like that it's quite likely related to mmap...
The problem here is not "shared writable mmap" Vitaliy has meant but it looks like it's the "exec" mount option being dropped (correctly) for unprivileged ntfs-3g process. Adding it to the end of the mount options in fstab should make the app work. If not then the mount must be done by root or ntfs-3g must be setuid root.
So, this indeed seems to be a mount configuration problem and sometimes mmapping files for execution is denied. 'exec' is not a missing functionality but it's denied due to security reasons in certain mount scenarios.
Nevertheless wine shouldn't crash if it's possible but report such errors to the user, so they would have a chance to fix the issue themself.
Of course if the app crashes then you really don't have anything to do, besides not misleading users why it's not a Wine fault ;-)
Regards, Szaka