On Wed Mar 29 12:44:35 2023 +0000, Joel Holdsworth wrote:
Yeah, although maybe it's not a *big* problem?
Well to be more precise, it's a tricky problem. Fortunately it's quite a well-contained problem, that - as you correctly say, only happens in a corner case. I agree with you my patch has a hacky feel to it. However, the issue with bad hacks is that they tend to get out of hand leading to wider behavioural problems and development headaches. By contrast, I think the hackiness of my patch is quite well contained:
- It only executes in an edge case.
- It's not much code.
- It's execute quickly.
- And it has unit tests.
To me, the impact seems a lot less than throwing out the usage of POSIX access flags.
if we really need to change the file mode, why didn't we just have the
more permissive mode in the first place? To me it's two reasons:
- Host integration. From a user stand-point, if a UNIX application
wanted to make a file read-only, it would do it using `chmod`. If a Windows application running in Wine wants to do the same thing, I would expect Wine to do it in the same way. 2. Limitations of the POSIX/Linux API. When you open a file you have to declare all the access you will ever want up front, and you can't upgrade or downgrade it later. Furthermore, UNIX doesn't have the same access granularity as NT. You can't open a file for writing extended attributes, while also opening it read-only. This is why we have to open non-user-writable files for writing using `chmod`.
I like the idea of always relying on metadata (including Erich's
hidden-directory proposal) better. Ok, lets talk about that. So I think if we did implement all the storage methods I listed above, we would still need some kind of fallback, so I think we certainly would sometimes need hidden directories - or something similar. But I'm really not sure about it. In regard to fragility, it seems to me that having the hidden directory is going to be more fragile. It would be very easy for the files to be separated from their attributes, for example. Users would have to know to keep each file together with its hidden directory. But the bigger question I have is how to implement it? The issue I see is that if the file is opened with `FILE_READ_ATTRIBUTES` or `FILE_WRITE_ATTRIBUTES` we need to open both the file and the file containing the DOS attributes i.e. we have to hold on to two files with two fds. Alternatively, we could use the `get_handle_unix_name` server request to get the path from the NT file handle when needed. But then we have a different kind of TOCTOU issue, because the file might have been moved on the UNIX side since it was opened. Also, are there threading issues? Is it possible to have multiple accessors to the attributes file? Or would the attributes have to be read/updated in server? Perhaps @ehoover can comment on this, but I'm worried that these concerns also apply to his patches. Shouldn't reparse points be using (Samba inspired?) extended attributes instead? But if we care to support reparse points on tmpfs, then we will need hidden directories some of the time at least.
FWIW I *really* dislike the idea of a hidden directory, it just feels wrong and clunky to me, and doesn't integrate well with the host at all.
tmpfs not supporting reparse points seems fine if that's the worry here; the reason Read-Only is different is that it's a basic feature of all Windows filesystems, not just more advanced ones (like NTFS), so it never fails on Windows, anywhere, even on FAT filesystems.
So apps on Windows can fail to use reparse points if used on a filesystem that doesn't support them, so they likely can expect it. But not the Read-Only attribute, that's why I find the current handling fine for tmpfs…