October 2021 - Wine-Devel - list.winehq.org

Re: RFC: Reparse Point/NT Symlink Support [3]

by Erich E. Hoover

On Thu, Sep 30, 2021 at 2:31 AM Alexandre Julliard <julliard(a)winehq.org> wrote: > > "Erich E. Hoover" <erich.e.hoover(a)gmail.com> writes: > > > If this doesn't sound too crazy then I can put together the > > modifications to make this happen. As part of that I'd like to > > introduce a tool (command 'wineprefix'?) that configures the Unix > > environment properly for Linux/BSD to allow the shell to function with > > this variadic symlink so that users like Martin Storsjö (and myself) > > can just run the tool to be dropped into a shell where ${WINEPREFIX} > > inside a symlink will be treated appropriately. (Part of why it's > > taken me a while to respond to this thread has been putting together a > > "proof of concept" of this tool to make sure that the idea works, > > which I can now confirm.) Please let me know what you guys think, > > hopefully this sounds better to folks. > > You are still trying too hard to shoehorn the complexity of reparse > points into working Unix symlinks, which makes it necessary to depend on > all kinds of exotic non-portable functionality. I think that it's a good idea to make it possible to interpret the links outside of Wine for the majority of users, there are a lot of ways to solve this problem that would make it impossible to do this using any combination of standard tools. > You should forget about making these transparent at the Unix > level. Focus on implementing the full semantics of reparse points, > including arbitrary tags and data, in a generic, easily extendable way, > using only standard Posix APIs. This is a pretty trivial update to the existing implementation, that will make symlinks that look like (<REPARSE-TAG> is encoded): <REPARSE-TAG>arbitrary data > Once you have this working for a range of different tags, with tests to > confirm compatibility, we can think about what subset of reparse points > would make sense as pure Unix symlinks, and add a special case for > these. Okay, what exactly are you looking for here? That you get the same thing back that you put in? Just like Unix symlinks, you can store any sort of arbitrary text/unicode/garbage in a reparse point for any tag (if you are so inclined). The OS may not know what to do with that tag unless you write a filter for it, but you can store anything that you want. Best, Erich

Oct. 1, 2021

[PATCH 3/3] makedep: Don't use -fno-builtin for importlibs.

by Jacek Caban

Signed-off-by: Jacek Caban <jacek(a)codeweavers.com> --- While not very important, the original check was mostly for msvcrt importlibs. We disable builtins for entire crt modules anyway and other importlibs should be fine with builtins enabled. tools/makedep.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)

Oct. 1, 2021