On Fri, Dec 19, 2014 at 2:52 AM, Alexandre Julliard julliard@winehq.org wrote:
"Erich E. Hoover" erich.e.hoover@gmail.com writes:
Currently only Linux extended attributes are supported, when they are not available at compile time the ports implementation will fall back to a "not-supported" return and any such attributes will be ignored. It is necessary to place this feature in ports so that Mac and FreeBSD can be supported separately, as the semantics of these APIs are quite different on such systems (patches to come after this initial implementation).
That doesn't mean they should go into ports, especially not as such non-standard functions. Unless you really have to use them all over the place, they should remain in ntdll.
Well, this was our logic: *) We suspect that you may want patch 4 (108301) implemented in the wineserver so that attributes are stored like they are for fstat() on file creation (to prevent problems with lockfiles). *) We need extended attribute support in the wineserver to implement security descriptors/ACLs (which, unfortunately, cannot be done in ntdll). *) You may want to expose extended attributes as a winelib convenience feature for porting your customer’s applications.
We could also move all the file information gathering to the wineserver, but we suspected that the overhead in doing that was not something that you’d be a huge fan of.
I’m very open to changing the interface, I would have preferred to use the standard Linux interface - but Mac OS X screws that all up by having a different number of parameters for the same functions. We could use the BSD or Solaris interface if you prefer, but they are quite a bit different than what most people would expect (if they’re familiar with the Linux/OSX interface).
Best, Erich