In the ntdll file handling code, there are currently two duplicated file info setting functions: `get_file_info` and `fd_get_file_info`. One pasted on path strings, and the other based on file descriptors respectively. This patch set simplifies the code by unifying both functions into a single function ~~powered by `fstatat` instead of `lstat` and `fstat`~~.
--
v2: ntdll: Unify get_file_info and fd_get_file_info.
https://gitlab.winehq.org/wine/wine/-/merge_requests/942
Changes since last MR:
- Store list entry inside of `struct uia_node` instead of doing linear search for removal.
- Replace `WARN` with `ERR` if provider thread shuts down with nodes still in the provider thread list.
- Use `wine/rbtree.h` for looking up HUIANODEs by runtime ID.
- Get rid of `struct uia_node *container_node` inside of `struct uia_provider`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/943
Add the ability to disconnect nested node providers, and return element properties for nested nodes.
--
v2: uiautomationcore: Add UIAutomationType_Element property support for nested node providers.
uiautomationcore: Implement UiaDisconnectProvider.
uiautomationcore: Track all HUIANODEs returned from the provider thread.
https://gitlab.winehq.org/wine/wine/-/merge_requests/908
In the ntdll file handling code, there are currently two duplicated file info setting functions: `get_file_info` and `fd_get_file_info`. One pasted on path strings, and the other based on file descriptors respectively. This patch set simplifies the code by unifying both functions into a single function powered by `fstatat` instead of `lstat` and `fstat`.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/942
> ...
>
> My gut is that if extended attributes are "universal enough"
> (and usable enough), and we can easily implement DOS attributes over
> them, modulo slight differences in the API, then there isn't really any
> need to implement something truly portable. I could be wrong about this,
> though.
What platforms do you consider to be important here? I ask because the current implementation (without fallback) supports Linux, Mac OS, FreeBSD, and NetBSD. That seems to me to be the "important" ones.
> > There is also the storage of [NT extended-attribute (EA)](https://learn.microsoft.com/en-us/windows-hardware/drivers/ddi/ntifs/n…) values to consider, when we move toward a non-stub implementation of this feature.
> >
> > Perhaps it would be preferable to produce a design that can be encompass all these issues.
The NTFS spec separates DOS Attributes (Flags) from Extended Attributes (EA). I would not recommend mixing the two, for fear of an accidental name collision. If you want to design a fallback mechanism that supports both of these features the same way, then I would suggest structuring it like so:
```
.WINE_METADATA/<filename>/<feature>
```
That way when a copy/move operation is performed on a file then it's easier to copy both features together.
> I don't have a good read on this, personally. I suppose it at least
> partly depends on whether NT extended attributes are used by any
> program. I'm at least not aware of any usage?
I am not aware of any non-MS usage, but it is documented. So, I would not be surprised if some copy protection mechanism does something with it our chooses to do so at some point in the future. I do know that the Single Instance Storage (SIS) minifilter driver uses an extended attribute to "back reference" the single instance files to find the duplicates/originals.
> I think working out the design completely before submitting any patches
> would probably be a good idea.
>
> ...
If the OS list above is sufficient then I think we're covered, if we need a fallback implementation then this probably needs a little more thought.
--
https://gitlab.winehq.org/wine/wine/-/merge_requests/924#note_9410