Am 12.07.2020 um 22:29 schrieb carlos carlos@superkaos.org:
/* FIXME: this is O(n) ... probably can be improved */ LIST_FOR_EACH_ENTRY( dir, &change_list, struct dir, entry ) { if (get_unix_fd( dir->fd ) != unix_fd) continue; dir->notified = 1; break; }
I think I could try to implement a hash table to avoid the loop.
We have a red-black tree implementation that might come in handy here: see include/wine/rbtree.h
Be warned though that there's probably a reason why this hasn't changed yet - maybe we need to preserve the order somewhere, or need O(1) inserts, etc, or maybe the list is usually just a few entries long so the algorithmic complexity is less important than cache locality. Try to find an application that is affected by this, see where else change_list is used, ...
if (!obj->sd || !security_equal_sid( owner, sd_get_owner( obj->sd ) )) { /* FIXME: get Unix uid and call fchown */ }I think I need to figure out the uid from perhaps PAM? I am not sure, but I am willing to find out if you people think this is worthwhile. I don't know how useful fixing these things may be, but they may be a good way to get started. What do you think?
I am not an expert on this code, but my gut feeling is that a lot more infrastructure is needed. Wine doesn't have any multi-user capabilities on its own. The intention is that the Unix user running Wine is the sole owner of the "fake" windows installation (by default everything is in $HOME/.wine) and you can change whatever you want. Representing Unix users as Windows users inside a Wine prefix only makes sense if we aim to make multiple Unix users able to run applications in the same prefix concurrently, have them communicate with each other etc. Right now this is not our goal and I don't think users care much.