[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