[2/2] ntdll: Implement FILE_ATTRIBUTE_HIDDEN and FILE_ATTRIBUTE_SYSTEM support (take 6)
Ken Thomases
ken at codeweavers.com
Wed Oct 7 12:44:12 CDT 2009
On Oct 7, 2009, at 11:46 AM, Dan Kegel wrote:
> On Wed, Oct 7, 2009 at 9:21 AM, Ken Thomases <ken at codeweavers.com>
> wrote:
>> It would also be good to check for UF_IMMUTABLE|SF_IMMUTABLE to
>> determine
>> FILE_ATTRIBUTE_READONLY, and set UF_IMMUTABLE when setting
>> FILE_ATTRIBUTE_READONLY, although that's a bit of a digression from
>> what
>> you're directly working on in your patches.
>
> Why isn't readonly enough? Geez.
Hmm? You mean Wine's current tactic of checking the mode flags to
determine READONLY?
Well, Windows itself distinguishes the READONLY attribute as separate
from having/lacking write permissions on a file.
Also, Wine's current tactic falls down in the presence of ACLs. A
file may grant no permissions in its mode bits, but grant various
access through ACLs. Wine considers such a file READONLY even if some
users (even the current user) may write to it.
Lastly, Mac OS X presents normal permissions bits, possibly including
write permission, for file systems mounted read-only. Wine reports
such files as non-READONLY if they have write bits in the mode. One
might consider this a Mac OS X bug, but, again, permissions are
different from physical writability. ("You may, but you can't." ;-)
For those reasons, I was planning to follow your patch, when it
finally gets accepted, with one to augment the current mode check with
a call to access(2) if we have a file path. If access(..., W_OK)
succeeds, I'll clear the READONLY attribute, regardless of what the
mode bits say (but respecting the [US]F_IMMUTABLE flags). If it fails
with errno == EROFS, I'll set READONLY, regardless of the mode bits.
Regards,
Ken
More information about the wine-devel
mailing list