Well, it'd take up more space, presumably, whereas we get the system DOS attribute for free.
True - I guess we could fall back to Sambe extended attributes only if no more suitable native method is found.
The problem is that we probably need to update every available method that we implement, because it's the only way to be sure that file is in a consistent state at the end of the process - both in terms of Wine is doing with the file, and what other applications are doing.
I suppose we could skip and where necessary remove any redundant Samba attributes if a better method of storage was found.
Yeah, maybe it is better to be redundant after all. I mean, it's not like we're going to be setting the attribute on every file anyway...
If it's just FILE_ATTRIBUTE_READONLY that's stripping Unix write access, I would agree that the better thing to do there is just to use the DOS attributes to store it, instead of translating it to Unix ~write access.
I hadn't considered the possibility of doing away with he UNIX file access flags support entirely.
It certainly does make things tricky.
There will be similar issues if we add additional support for MacOS/BSD `st_flags` `UF_IMMUTABLE` (as per [Wine Bug #39366](https://bugs.winehq.org/show_bug.cgi?id=39366)).
The benefit is that you get idiomatic behaviour for the host OS. Windows read-only files will appear read-only in the GUIs, for example.
The problem is that mismatch in the semantics of these features compared to `FILE_ATTRIBUTE_READONLY` makes the implementation awkward.
I am prepared to put in the work to build as clean an implementation as is possible, but it would be good to have a rough agreement around the design before I go too much futher down the rabbit hole.
Yeah, personally I agree that translating these semantics to the host would be *nice*, but I'd rather have programs just work than have that integration [well, and without having to rely on runtime chmod() to do it.]
Honestly I'm not even sure that translating FILE_ATTRIBUTE_READONLY to ~0222 is even that nice of a feature? In my experience it's only really set on internal files like DLLs, which I wouldn't expect normal end users to be messing with *anyway*, and it actually kind of gets in the way by virtue of preventing prefix removal (without rm -f, anyway.)
I don't know what UF_IMMUTABLE actually does, but if it's the same kind of thing I'm not sure it's worthwhile either.
Of course, this is all *my* opinion (on what we should do and how we should do it), this probably deserves a weigh-in from others as well.