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.
Does that actually matter in practice? I.e. are there cases where a Windows program sets FILE_WRITE_ATTRIBUTES access but not FILE_WRITE_DATA access?
Msys2 does this in its implementation of the `unlink()` syscall:
https://github.com/msys2/msys2-runtime/blob/msys2-3_3_6-release/winsup/cygwi...
See this bug: https://bugs.winehq.org/show_bug.cgi?id=50771
Msys2 pacman creates a database lock file, which it fails to delete after use, because Wine can't open the file handle for deletion.
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.
Ugh, I'm surprised this isn't a more standardized feature, it's missing from basically everything but Linux and FreeBSD. Maybe we just leave it as unimplemented; it wouldn't be a regression in that case. Or maybe we just implement a fallback based on storing path names and hang the TOCTOU issues.
I think the latter is acceptable. It would be good to have this working for MacOS users.