Re: today's git broke winetricks gecko :-(
On Mon, Nov 16, 2009 at 11:29:51PM +0100, Ove Kaaven wrote: > Jacek Caban skrev: > > Well, I hope that a side effect of installation during wineprefix > > creation is that it will force packagers to package gecko > > You can't *force* the creation of packages which would likely fail to > meet the requirements for inclusion into Debian's main archive. Even if > I didn't think the package's build system is a problem, the ftpmasters > likely would. I btw thought of actually building wine-gecko using mingw instead of just distributing the .cab. Just did not have the time to try it in the .spec file. This is also the 1 problem I see with distro inclusion here, so far I just have it in my openSUSE buildservice repos. Ciao, Marcus
Re: today's git broke winetricks gecko :-(
On Mon, Nov 16, 2009 at 5:52 PM, Ove Kaaven wrote: > (It is actually for similar reasons that binaries must be buildable on a > clean system (say, a build daemon), without any special (non-free) tools > or sourceless libraries. Magic libshell32.a in the source package fails > this requirement, and so does usage of non-free cabinet.dll to make cab > file.) I don't suppose the build could be fixed? "The wine-gecko build is unclean" is a separate issue from "Wine-gecko should/shouldn't be a run-time requirement". Both of them are important issues, and the unclean gecko build would still be important (if not as visible) without this change. I wouldn't expect anything less of Debian than to refuse to include wine-gecko in the free parts or as a download at startup for exactly the reasons you describe. I hope they do. These are valid concerns, and someone has to stubbornly insist that they be addressed, pointing to clear, inhuman policies. As for the run-time requirement, I think it's good for calling attention to the fact that gecko is a requirement for a fully functional Wine (even though configure doesn't warn about it) and that "when needed" is too late, but it's absolutely useless in terms of *forcing* packagers to do anything and much more annoying than it needs to be for calling attention to the requirement. (It also doesn't seem to actually find the .cab file, even though I'm sure I've put it in the right place, but that's a third issue that I'll have to test more carefully and possibly file a bug for.) Providing, say, an environment variable that one could use to specify a path of the .cab would make things much less annoying for me (I'd have a work-around for the aforementioned bug-or-user-error, and I wouldn't have to copy a .cab whenever I make a new wine install in a new directory, which is fairly often.) and would make 'winetricks gecko' fixable. You'd still see the message box when invoking wine for the first time absolutely any other way, or if you do it wrong, so I don't see the problem there. It also seems to me that a --disable-gecko-downloader configure switch that would disable the dialog COMPLETELY (even "when needed") would put gecko on equal footing with optional library requirements. It would mean: * You can warn about the perils of not having gecko at configure time. * If gecko is installed properly, it's used properly, installed at prefix creation time. * If gecko is not installed properly, programs that need it will simply fail, and you'll see an ERR in the console, as well as a nice "HTML rendering is disabled" message you wouldn't get from other components. -- Vincent Povirk
Re: [RFC] Handle process token groups in server/file.c::sd_to_mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Rob Shearman wrote:
> While I agree that there is a problem that needs to be fixed, I'm not
> sure this is the right approach. I think you need to take a step back
> and consider the meanings of the different SIDs in a token by default
> and how they map wine running inside the Unix permissions model. For
> example, maybe these mappings make sense:
>
> security_local_sid -> user + group + others
> security_interactive_sid -> user + group + others
> alias_users_sid -> user + group + others?
>
> Now it's likely that the bugs you are trying to fix are trying to set
> the SD for a file to alias_admins_sid or alias_users_sid. The mapping
> for alias_admins_sid is less clear - one could argue that all Wine
> users on a given system would present themselves as admins to apps,
> but then again the apps may be restricting permissions on a file
> because it contains sensitive data and should only be shared with
> other admins (which would be trusted as such, unlike other users on a
> system).
>
Currently, the wine NT DACL -> unix permission code works as follows:
* The permissions start as deny all.
* If the world SID is granted a permission, then that permission is
added to both owner and others.
* If the owner SID is explicitly granted a permission, then that
permission is added to owner.
* If the world SID is denied a permission, then that permission is
removed from both owner and others.
* If the owner SID is explicitly denied a permission, then that
permission is removed from owner.
This means that if neither owner nor world are listed in the NT DACL,
the owner of the file is denied all permissions on that file, even if
they would have been granted access by one of their groups.
Windows Access Control Lists act as a series of grant/deny Access
Control Entries, and the entire Access Control List must be consulted to
determine the rights of the user. If none of the user, the user's
groups or the world SID are mentioned in the DACL, then that user is
denied all permissions. No SIDs are treated specially (not even SYSTEM).
Unix permissions and Access Control Lists act as a set of definitive
Access Control Entries, and the first Access Control Entry that applies
to the user or one of their groups is used to determine the rights of
the user. The superuser is treated specially, and is always granted
permission (unless squashed by the filesystem or a security module).
As the owner permission is consulted before any entries in the ACL, the
owner permission cannot be overridden by an entry in the ACL.
I have modified my patch to only check the groups in the process token
if the owner of the process is the owner of the file.
This patch:
* in server/token.c:
* exposes token_sid_present(), which tests whether an SID is present
in the token.
* in server/file.c::sd_to_mode():
* Sets the local boolean variable user_is_owner if the owner of the
process and the owner of the file are the same.
* Denies permissions from the owner of the file if user_is_owner is
true and the SID denying permissions is present in the token.
* Grants permissions to the owner of the file if user_is_owner is true
and the SID granting permissions is present in the token, and is not a
deny-only SID.
The patch seeks to ensure that the owner of the file is granted and/or
denied permissions based on the permissions of their groups. At the
moment, it only does this if the owner of the file is also the owner of
the process, as I don't know how to look up the groups of other users.
The only other way I can see of doing this is to pre-process the SID and
add a grant and/or deny ACE for the owner based on the access given by
their groups.
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksB7AoACgkQTHDAI68NsumA4wCfc61LXxavFTe82jXC2DjTMrXH
iN0An3+hI0dFBYbsb7hY3JRyjXTD0eD3
=Ch74
-END PGP SIGNATURE-
server/file.c |7 +--
server/security.h |1 +
server/token.c|2 +-
3 files changed, 7 insertions(+), 3 deletions(-)
diff --git a/server/file.c b/server/file.c
index a74de14..db9dd5f 100644
--- a/server/file.c
+++ b/server/file.c
@@ -461,6 +461,7 @@ mode_t sd_to_mode( const struct security_descriptor *sd,
const SID *owner )
if (present && dacl)
{
const ACE_HEADER *ace = (const ACE_HEADER *)(dacl + 1);
+int user_is_owner = security_equal_sid( owner, token_get_user(
current->process->token) );
ULONG i;
for (i = 0; i < dacl->AceCount; i++, ace = ace_next( ace ))
{
@@ -485,7 +486,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd,
const SID *owner )
if (access & FILE_EXECUTE)
denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
}
-else if (security_equal_sid( sid, owner ))
+else if (security_equal_sid( sid, owner ) ||
Re: today's git broke winetricks gecko :-(
2009/11/17 Juan Lang : >> However, I refuse to force the Wine >> package to depend on it because this wine-gecko-1.0 package doubles >> the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 >> package). I realise that this will not be required to download on >> every upgrade, but I also can't predict when wine-gecko releases are >> made. > > What's the download size got to do with anything? Do you want to > force people to use an old, unsupported version of Wine because its > download size is smaller? Please, don't conflate unrelated issues. If a previously-optional component is now deemed to be mandatory, and that component *on its own* happens to double the download size required to install Wine, I consider that a problem. Not everyone has a cable or ADSL2+ connection. >> say it is". If this was something like, e.g., my decision to not >> separate OpenGL from the core Wine package, it wouldn't be a real >> problem (OpenGL support is used by the majority of Wine users, and >> takes up very little space in the binary distrobution), but it's not. > > Says who? Don't make unsupported claims, please. I've never used > OpenGL support in Wine, but I have used gecko. Most users, espcecially new users, seem to want to use Wine for games. Perhaps they are merely the most vocal. > Jacek's justification has been the number of bugs that are closed > invalid due to an invalid configuration. Strongly encouraging people > to install gecko would reduce the time we all spend looking at bogus > bug reports. Personally, I think that's worth considering, especially > because developer man hours are perhaps the most scarce resource for > the Wine project. I understand this, but it's a quick-fix to a problem that has long-term ramifications which were not even considered when the decision was made. It is simply not satisfactory that ALL use-cases of Wine now present the users with the "you need Gecko" dialog. >wine cmd /c echo yes now downloads gecko. How can you possibly justify this?
Re: today's git broke winetricks gecko :-(
Jacek Caban skrev: > Ove Kaaven wrote: >> Jacek Caban skrev: >> >>> Well, I hope that a side effect of installation during wineprefix >>> creation is that it will force packagers to package gecko >>> >> >> You can't *force* the creation of packages which would likely fail to >> meet the requirements for inclusion into Debian's main archive. Even if >> I didn't think the package's build system is a problem, the ftpmasters >> likely would. >> > > Then I can't see better solution for Debian users than downloading Gecko > on wineprefix creation. It's not perfect, but we don't have much choice. It really should be optional. Making it mandatory for a program to go out on the Internet, download 'untrusted' binaries, and then running them, without the user actually having (and knowing) a reason for the program to do this, might be too much for some security-conscious (and spyware-hating) people to handle. Debian packagers have been forced to turn off that kind of automatic behaviour before. Hence, it's possible that downloading Gecko on wineprefix creation is not a solution for Debian users at all, and that any attempt at this will result in a release-critical bug (with a "security problem" tag to boot, claiming "a dns spoof could mean someone could control your computer" etc) requiring this to be turned off in the Debian package. (It is actually for similar reasons that binaries must be buildable on a clean system (say, a build daemon), without any special (non-free) tools or sourceless libraries. Magic libshell32.a in the source package fails this requirement, and so does usage of non-free cabinet.dll to make cab file.) Maybe I could ask on debian-devel if there's a good way to handle this, maybe someone can come up with a good answer beyond the typical "upstream developers suck", or at least agree that a kludgy package might be acceptable in this case. (I'd need some time to prepare something to ask, though.) But in any case, I really don't think Gecko should be any less optional than, say, OpenGL, lcms, or ALSA/OSS/etc, without which Wine will reduce functionality (even at runtime, not only compile time), but still allow programs that don't need that functionality to work. You don't need CUPS to run games and you don't need OpenGL to run Office, why should you need Gecko for anything that won't ever do any HTML rendering? There's often much to be said for only installing what you need... and some people like that. (Wasn't there a reason Gentoo was popular?)
Re: today's git broke winetricks gecko :-(
> However, I refuse to force the Wine > package to depend on it because this wine-gecko-1.0 package doubles > the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 > package). I realise that this will not be required to download on > every upgrade, but I also can't predict when wine-gecko releases are > made. What's the download size got to do with anything? Do you want to force people to use an old, unsupported version of Wine because its download size is smaller? Please, don't conflate unrelated issues. > say it is". If this was something like, e.g., my decision to not > separate OpenGL from the core Wine package, it wouldn't be a real > problem (OpenGL support is used by the majority of Wine users, and > takes up very little space in the binary distrobution), but it's not. Says who? Don't make unsupported claims, please. I've never used OpenGL support in Wine, but I have used gecko. Jacek's justification has been the number of bugs that are closed invalid due to an invalid configuration. Strongly encouraging people to install gecko would reduce the time we all spend looking at bogus bug reports. Personally, I think that's worth considering, especially because developer man hours are perhaps the most scarce resource for the Wine project. --Juan
Re: today's git broke winetricks gecko :-(
2009/11/17 Jacek Caban : > I can see three types of Wine users: > > - regular users > They use Wine packages that should guarantee presence of Gecko (as Wine > dependency or in Wine package, depends on packagers preferences). The > current situation will probably force packagers to do the right thing > > - Wine developers > I'm surprised how many developers are affected by this change. It means that > developers were not aware of the right way to install Gecko (probably > because winetricks is too good :-) ). I'm sure it will change now. > > - Users who compile Wine themselves > Well... the information about proper Gecko installation is easy to find and > it's pointed on every wineprefix creation. They should survive as long as > they read what's . > > Given that, I think this change will force changes that will allow us to > forget about the problem soon. You're missing a type of user that has been quite vocal on this thread: - Users who have no need for Gecko These are "regular users" who don't use applications or games that require MSHTML/Gecko/IE6/whatever. They don't view .chm files either, and most of them don't run the test suite. This group has been completely forgotten in the decision to force Gecko. OK, so you can hit "Cancel" to stop the download. This is *not* satisfactory. As it is at the moment, Gecko sits half-way between an opt-in and an opt-out system. It should be made one or the other - either force it to be installed (by all package maintainers) on first install and then have it optionally removed *without* causing a stupid pop-up box saying it's missing, or have a button in winecfg or similar that downloads it if it is missing. As the maintainer of WineHQ's Debian packages, I have produced a new wine-gecko-1.0 package for use with 1.1.33, something that I was considering for a long time. However, I refuse to force the Wine package to depend on it because this wine-gecko-1.0 package doubles the required download (7.8MB wine-gecko-1.0, 7.8MB wine 1.1.33 package). I realise that this will not be required to download on every upgrade, but I also can't predict when wine-gecko releases are made. Currently, the wine-gecko-1.0 package I have produced depends on Wine. I may need to rethink this to cater for user groups 2 and 3 above. Furthermore, I have not yet packaged earlier versions of wine-gecko for use with earlier versions of Wine, but I believe I have had the foresight to think of this potential situation. This is in direct contrast to the obviously low about of thought that went into the change to how Wine downloads Gecko. 2009/11/17 Jacek Caban : >> You can't *force* the creation of packages which would likely fail to >> meet the requirements for inclusion into Debian's main archive. Even if >> I didn't think the package's build system is a problem, the ftpmasters >> likely would. > > Then I can't see better solution for Debian users than downloading Gecko on > wineprefix creation. It's not perfect, but we don't have much choice. It shouldn't even be an option. What's wrong with adding an opt-in button to "winecfg"? The rigidity of proponents of the "new way" is disheartening. The feeling coming across is "this way is better for everyone because we say it is". If this was something like, e.g., my decision to not separate OpenGL from the core Wine package, it wouldn't be a real problem (OpenGL support is used by the majority of Wine users, and takes up very little space in the binary distrobution), but it's not. Gecko is purely optional (although not recommended, "winetricks ie6" does get some apps working where Gecko doesn't), and quite large.
Re: today's git broke winetricks gecko :-(
On Mon, Nov 16, 2009 at 12:58 PM, Jacek Caban wrote: > You should understand, that we don't want users to have problems due to > *lack* of Gecko. Any solution like moving installation to winecfg means that > most user (at least these, who don't get Gecko from their distro packages) > will have this problem. You also didn't give me any single good reason to > not install Gecko properly. Instead you just said that you pollute winetest > results with your bad configuration. Isn't winetest web configured to reject certain classes of test results already? I seem to recall Alexandre adding some magic to winetest and the site to reject reports or flag them if they were with a sha1hash that did not match a git revision. Could we not do something like this with gecko? If it's not installed then just ignore those results? -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: today's git broke winetricks gecko :-(
Ove Kaaven wrote: Jacek Caban skrev: Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would. Then I can't see better solution for Debian users than downloading Gecko on wineprefix creation. It's not perfect, but we don't have much choice. Jacek
Re: today's git broke winetricks gecko :-(
Jacek Caban skrev: > Well, I hope that a side effect of installation during wineprefix > creation is that it will force packagers to package gecko You can't *force* the creation of packages which would likely fail to meet the requirements for inclusion into Debian's main archive. Even if I didn't think the package's build system is a problem, the ftpmasters likely would.
Re: [PATCH] jscript: Implement decodeURIComponent
Jacek Caban wrote:
Hi Andrew,
Andrew Eikum wrote:
---
dlls/jscript/global.c | 104
-
dlls/jscript/tests/api.js | 20 +
2 files changed, 122 insertions(+), 2 deletions(-)
+while(*ptr == '%') {
+if(hex_to_int(*(ptr+1)) < 0 || hex_to_int(*(ptr+2)) < 0) {
+WARN("Invalid hex sequence: 0x%x 0x%x\n", *(ptr+1),
*(ptr+2));
+SysFreeString(str);
+return E_FAIL;
URIError should be thrown here. If it's not, then you should put FIXME
here. Same for other places where you return E_FAIL.
+}
+ptr += 3;
+++buf_len;
+}
+octets = heap_alloc(buf_len);
You don't check allocation failure and leak octets here. You may avoid
dynamic allocation at all by processing one utf8 char at the time. Then
you know that it's not longer than 4 bytes. Ecma specification describes
it well, although you may simplify the algorithm by checking number of
bytes from the first byte, fetching bytes to the array and then use
MultiByteToWideChar for conversion to UTF-16 and validation.
Thanks,
Jacek
Thanks for looking it over, Jacek. I've resent with your suggestions.
Andrew
Re: [PATCH] jscript: Implement decodeURIComponent
Hi Andrew,
Andrew Eikum wrote:
---
dlls/jscript/global.c | 104
-
dlls/jscript/tests/api.js | 20 +
2 files changed, 122 insertions(+), 2 deletions(-)
+while(*ptr == '%') {
+if(hex_to_int(*(ptr+1)) < 0 || hex_to_int(*(ptr+2)) < 0) {
+WARN("Invalid hex sequence: 0x%x 0x%x\n", *(ptr+1),
*(ptr+2));
+SysFreeString(str);
+return E_FAIL;
URIError should be thrown here. If it's not, then you should put FIXME here.
Same for other places where you return E_FAIL.
+}
+ptr += 3;
+++buf_len;
+}
+octets = heap_alloc(buf_len);
You don't check allocation failure and leak octets here. You may avoid dynamic
allocation at all by processing one utf8 char at the time. Then you know that
it's not longer than 4 bytes. Ecma specification describes it well, although
you may simplify the algorithm by checking number of bytes from the first byte,
fetching bytes to the array and then use MultiByteToWideChar for conversion to
UTF-16 and validation.
Thanks,
Jacek
Re: today's git broke winetricks gecko :-(
joerg-cyril.hoe...@t-systems.com wrote: Jacek, - I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why. Did you read the page from the link that is on the dialog informing about missing Gecko? What part from wiki/Gecko did you have in mind? Regarding the above, I see the following explanation: http://wiki.winehq.org/Gecko Wine 1.1.33 and later will download Gecko when a prefix is created. 'If your distribution of Wine doesn't put the .cab file in the right place for you, you can avoid problems by putting it there yourself as follows: (...)' Aha -- I did not run winetest creating a prefix at the same time. I created the prefix earlier, running winecfg. So that's why winetest did not download Gecko and why I saw no dialog box at winetest time. I can see three types of Wine users: I don't find myself in the description you gave. You're a user compiling Wine himself. I've a feeling that I'm misunderstood. I have nothing against Gecko. I simply tend to test apps in a minimal configuration environment. Optional packages like Gecko are not part of that environment, and I always saw a risk that a nMB third-party Gecko package introduces its own bugs when I want to find out about the ones in Wine (or the app). If you run winetest, you *should* have Gecko installed. Otherwise your test results are confusing. Also bugs in Gecko are as bad for Wine as Wine own bugs. Consider Gecko as a part of mshtml.dll. None but three of the many apps that I've tested depended on HTML/Gecko. That is my experience. Sometimes, when I thought Gecko should be needed (to view advanced .hlp or .chm files), I tested with Gecko -- or so I thought -- but it didn't help rendering the .hlp pages (witness bug #17682). .chm files require Gecko and if they don't work, it's due to bugs that you claim to want to find. allow us to forget about the problem soon What actually is *the* problem? The problem is that you have to click install during wineprefix creation. The fix is to install Gecko correctly. It seems to me like "Gecko is not compulsory" is the problem in your eyes, isn't it? It's surely strongly recommended. The configuration without Gecko is still possible, you just have to click cancel. No better solution was proposed so far. This is not my experience. To me, Gecko appears strictly optional, and rarely needed (for the kind of apps that I'm running). I've no problem with the Wine team now declaring Gecko as compulsory, and would then start to use it. But the wiki/Gecko page right now does not say that it is so. Feel free to change wiki. My problem, namely rm -rf ~/.wine; wine /c cmd or wine xyz hanging in a dialog box or believing that it is allowed to access the network, then of course would go away (at the cost of a larger .wine tree). Again, install Gecko properly if you don't want the dialog box. You should understand, that we don't want users to have problems due to *lack* of Gecko. Any solution like moving installation to winecfg means that most user (at least these, who don't get Gecko from their distro packages) will have this problem. You also didn't give me any single good reason to not install Gecko properly. Instead you just said that you pollute winetest results with your bad configuration. Jacek
Re: today's git broke winetricks gecko :-(
Jacek, >> - I tried to think positively about it and expected the winetest-1.1.33.exe >> to install Gecko and perform the mshtml tests when online. Curiously they >> were skipped. I have yet to find out why. >Did you read the page from the link that is on the dialog informing >about missing Gecko? What part from wiki/Gecko did you have in mind? Regarding the above, I see the following explanation: http://wiki.winehq.org/Gecko >Wine 1.1.33 and later will download Gecko when a prefix is created. Aha -- I did not run winetest creating a prefix at the same time. I created the prefix earlier, running winecfg. So that's why winetest did not download Gecko and why I saw no dialog box at winetest time. >I can see three types of Wine users: I don't find myself in the description you gave. I've a feeling that I'm misunderstood. I have nothing against Gecko. I simply tend to test apps in a minimal configuration environment. Optional packages like Gecko are not part of that environment, and I always saw a risk that a nMB third-party Gecko package introduces its own bugs when I want to find out about the ones in Wine (or the app). None but three of the many apps that I've tested depended on HTML/Gecko. That is my experience. Sometimes, when I thought Gecko should be needed (to view advanced .hlp or .chm files), I tested with Gecko -- or so I thought -- but it didn't help rendering the .hlp pages (witness bug #17682). >allow us to forget about the problem soon What actually is *the* problem? It seems to me like "Gecko is not compulsory" is the problem in your eyes, isn't it? This is not my experience. To me, Gecko appears strictly optional, and rarely needed (for the kind of apps that I'm running). I've no problem with the Wine team now declaring Gecko as compulsory, and would then start to use it. But the wiki/Gecko page right now does not say that it is so. My problem, namely rm -rf ~/.wine; wine /c cmd or wine xyz hanging in a dialog box or believing that it is allowed to access the network, then of course would go away (at the cost of a larger .wine tree). Regards, Jörg Höhle.
Re: WineD3D: fix bug 20522
Roderick Colenbrander writes: > This patch fixes bug 20522 which was uncovered by 32-bit dibsection > support. I have added a test to show that the patch is correct. Like > with Blt the results varry depending on the drivers. It doesn't work here: ../../../tools/runtest -q -P wine -M ddraw.dll -T ../../.. -p ddraw_test.exe.so visual.c && touch visual.ok visual.c:2349: Test failed: got R 80 G 00 B 00, expected R 00 G FF B 00 make: *** [visual.ok] Error 1 -- Alexandre Julliard julli...@winehq.org
Re: today's git broke winetricks gecko :-(
Marcus Meissner wrote: On Mon, Nov 16, 2009 at 05:08:21PM +0100, Jacek Caban wrote: Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko The brutal true is that we had a very bad situation for a long time. I can see three types of Wine users: - regular users They use Wine packages that should guarantee presence of Gecko (as Wine dependency or in Wine package, depends on packagers preferences). The current situation will probably force packagers to do the right thing The Wine packages for openSUSE now do the right thing, since last Friday ;) It will hopefully get this way into openSUSE 11.3 too. Thanks! I've added openSUSE to the list on: http://wiki.winehq.org/Gecko It would be great if others could update the list for their distros. AFAIK Ubuntu packages also support Gecko, but I've never touched it, so I can't be sure. I don't know about other distros. Jacek
Re: [RFC] Handle process token groups in server/file.c::sd_to_mode
2009/11/16 Ben Peddell : > This proposed patch (which I believe will contribute toward solving bugs > 17672, 19588 and 20643, and any others where the permissions are set too > restrictive) exposes the token_sid_present call in token.c, > and uses it to check the SIDs in the security descriptor against those > in the process token. > > Are there any changes anyone can think of before I submit it to > wine-patches? > > Is there a better (already exposed) way of checking a SID against the > process token's group list? Hi Ben, While I agree that there is a problem that needs to be fixed, I'm not sure this is the right approach. I think you need to take a step back and consider the meanings of the different SIDs in a token by default and how they map wine running inside the Unix permissions model. For example, maybe these mappings make sense: security_local_sid -> user + group + others security_interactive_sid -> user + group + others alias_users_sid -> user + group + others? Now it's likely that the bugs you are trying to fix are trying to set the SD for a file to alias_admins_sid or alias_users_sid. The mapping for alias_admins_sid is less clear - one could argue that all Wine users on a given system would present themselves as admins to apps, but then again the apps may be restricting permissions on a file because it contains sensitive data and should only be shared with other admins (which would be trusted as such, unlike other users on a system). -- Rob Shearman
Re: today's git broke winetricks gecko :-(
On Mon, Nov 16, 2009 at 05:08:21PM +0100, Jacek Caban wrote: > Well, I hope that a side effect of installation during wineprefix > creation is that it will force packagers to package gecko The > brutal true is that we had a very bad situation for a long time. I > can see three types of Wine users: > > - regular users > They use Wine packages that should guarantee presence of Gecko (as > Wine dependency or in Wine package, depends on packagers > preferences). The current situation will probably force packagers to > do the right thing The Wine packages for openSUSE now do the right thing, since last Friday ;) It will hopefully get this way into openSUSE 11.3 too. Ciao, Marcus
Re: today's git broke winetricks gecko :-(
Tom Wickline wrote: Jacek, How does this work off line? If Wine cant download and install gecko at wineprefix creation then Wine wont work? And if so every time you create a wineprefix your going to have to be connected and the server is going to have to be up 100% of the time or Wine wont properly create a prefix.. You could time out and move to a backup server but it still begs the question of what if the servers are down, then what? Can you please comment on this.. The answer is not to use the downloader. You've just given another reasons to install Gecko properly. Jacek
Re: today's git broke winetricks gecko :-(
Steven Edwards wrote: Hi Jacek, On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban wrote: Did you read the page from the link that is on the dialog informing about missing Gecko? I've been kind of following this thread and see where Jörg is coming from. I don't think the argument about broken wine due to missing gecko makes much sense given the way we have other soft dependencies that can be missing if you build Wine yourself. A good example is the xml or opengl libraries. It's possible to have a working wine for specific needs without this package. If we are going to require this package for every wine install then I would argue we should not have any other soft dependencies either. These dependences are different because they are Linux dependences. There is no way we could tread Gecko the same way. If a packager has not packaged Gecko or a hacker has built from source it seems like winecfg should be invoked when a new prefix is created rather than prompting for the download. Maybe for the general usage case we should do it anyway. Alternatively, if we are going to have this hook in here to satisfy this dependency during prefix creation due to packagers not following a required guideline, maybe a little public ridicule will force them to fix the package. Something along the lines of 'your version of wine does not contain the gecko package, please contact the package maintainer and inform them about this issue' or something and let it proceed to download at least. Well, I hope that a side effect of installation during wineprefix creation is that it will force packagers to package gecko The brutal true is that we had a very bad situation for a long time. I can see three types of Wine users: - regular users They use Wine packages that should guarantee presence of Gecko (as Wine dependency or in Wine package, depends on packagers preferences). The current situation will probably force packagers to do the right thing - Wine developers I'm surprised how many developers are affected by this change. It means that developers were not aware of the right way to install Gecko (probably because winetricks is too good :-) ). I'm sure it will change now. - Users who compile Wine themselves Well... the information about proper Gecko installation is easy to find and it's pointed on every wineprefix creation. They should survive as long as they read what's . Given that, I think this change will force changes that will allow us to forget about the problem soon. Jacek
Re: today's git broke winetricks gecko :-(
On Mon, Nov 16, 2009 at 11:38 PM, Steven Edwards wrote: > Hi Jacek, > > On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban > wrote: > > Did you read the page from the link that is on the dialog informing about > > missing Gecko? > > I've been kind of following this thread and see where Jörg is coming > from. I don't think the argument about broken wine due to missing > gecko makes much sense given the way we have other soft dependencies > that can be missing if you build Wine yourself. A good example is the > xml or opengl libraries. It's possible to have a working wine for > specific needs without this package. If we are going to require this > package for every wine install then I would argue we should not have > any other soft dependencies either. > > If a packager has not packaged Gecko or a hacker has built from source > it seems like winecfg should be invoked when a new prefix is created > rather than prompting for the download. Maybe for the general usage > case we should do it anyway. Alternatively, if we are going to have > this hook in here to satisfy this dependency during prefix creation > due to packagers not following a required guideline, maybe a little > public ridicule will force them to fix the package. Something along > the lines of 'your version of wine does not contain the gecko package, > please contact the package maintainer and inform them about this > issue' or something and let it proceed to download at least. > > > -- > Steven Edwards > > "There is one thing stronger than all the armies in the world, and > that is an idea whose time has come." - Victor Hugo > > > Jacek, How does this work off line? If Wine cant download and install gecko at wineprefix creation then Wine wont work? And if so every time you create a wineprefix your going to have to be connected and the server is going to have to be up 100% of the time or Wine wont properly create a prefix.. You could time out and move to a backup server but it still begs the question of what if the servers are down, then what? Can you please comment on this.. Tom
[RFC] Handle process token groups in server/file.c::sd_to_mode
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
This proposed patch (which I believe will contribute toward solving bugs
17672, 19588 and 20643, and any others where the permissions are set too
restrictive) exposes the token_sid_present call in token.c,
and uses it to check the SIDs in the security descriptor against those
in the process token.
Are there any changes anyone can think of before I submit it to
wine-patches?
Is there a better (already exposed) way of checking a SID against the
process token's group list?
-
server/file.c |6 --
server/security.h |1 +
server/token.c|2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
-BEGIN PGP SIGNATURE-
Version: GnuPG v2.0.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
iEYEARECAAYFAksBcpAACgkQTHDAI68Nsuny6ACfXu3vvWS6O27Z/mfozb4e/ZMG
MYQAoItP8P75a3l54TYrLnQbk7lNyaaQ
=7QsU
-END PGP SIGNATURE-
server/file.c |6 --
server/security.h |1 +
server/token.c|2 +-
3 files changed, 6 insertions(+), 3 deletions(-)
diff --git a/server/file.c b/server/file.c
index a74de14..793c24a 100644
--- a/server/file.c
+++ b/server/file.c
@@ -485,7 +485,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd,
const SID *owner )
if (access & FILE_EXECUTE)
denied_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
}
-else if (security_equal_sid( sid, owner ))
+else if (security_equal_sid( sid, owner ) ||
+ token_sid_present( current->process->token, sid,
1 ))
{
unsigned int access = generic_file_map_access(
ad_ace->Mask );
if (access & FILE_READ_DATA)
@@ -509,7 +510,8 @@ mode_t sd_to_mode( const struct security_descriptor *sd,
const SID *owner )
if (access & FILE_EXECUTE)
new_mode |= S_IXUSR|S_IXGRP|S_IXOTH;
}
-else if (security_equal_sid( sid, owner ))
+else if (security_equal_sid( sid, owner ) ||
+ token_sid_present( current->process->token, sid,
0 ))
{
unsigned int access = generic_file_map_access(
aa_ace->Mask );
if (access & FILE_READ_DATA)
diff --git a/server/security.h b/server/security.h
index 39b1d2f..33cf5da 100644
--- a/server/security.h
+++ b/server/security.h
@@ -55,6 +55,7 @@ extern int token_check_privileges( struct token *token, int
all_required,
extern const ACL *token_get_default_dacl( struct token *token );
extern const SID *token_get_user( struct token *token );
extern const SID *token_get_primary_group( struct token *token );
+extern int token_sid_present( struct token *token, const SID *sid, int deny);
static inline const ACE_HEADER *ace_next( const ACE_HEADER *ace )
{
diff --git a/server/token.c b/server/token.c
index ce896ac..461e79d 100644
--- a/server/token.c
+++ b/server/token.c
@@ -776,7 +776,7 @@ int token_check_privileges( struct token *token, int
all_required,
return (enabled_count > 0);
}
-static int token_sid_present( struct token *token, const SID *sid, int deny )
+int token_sid_present( struct token *token, const SID *sid, int deny )
{
struct group *group;
wine-sd_to_mode-group-check.patch.sig
Description: Binary data
Re: today's git broke winetricks gecko :-(
Hi Jacek, On Mon, Nov 16, 2009 at 10:16 AM, Jacek Caban wrote: > Did you read the page from the link that is on the dialog informing about > missing Gecko? I've been kind of following this thread and see where Jörg is coming from. I don't think the argument about broken wine due to missing gecko makes much sense given the way we have other soft dependencies that can be missing if you build Wine yourself. A good example is the xml or opengl libraries. It's possible to have a working wine for specific needs without this package. If we are going to require this package for every wine install then I would argue we should not have any other soft dependencies either. If a packager has not packaged Gecko or a hacker has built from source it seems like winecfg should be invoked when a new prefix is created rather than prompting for the download. Maybe for the general usage case we should do it anyway. Alternatively, if we are going to have this hook in here to satisfy this dependency during prefix creation due to packagers not following a required guideline, maybe a little public ridicule will force them to fix the package. Something along the lines of 'your version of wine does not contain the gecko package, please contact the package maintainer and inform them about this issue' or something and let it proceed to download at least. -- Steven Edwards "There is one thing stronger than all the armies in the world, and that is an idea whose time has come." - Victor Hugo
Re: today's git broke winetricks gecko :-(
joerg-cyril.hoe...@t-systems.com wrote: Hi, wine cmd /c echo yes now downloads gecko. Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup. - How am I going to automate regression testing when it hangs waiting for a mouse click? - I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why. Did you read the page from the link that is on the dialog informing about missing Gecko? Jacek
today's git broke winetricks gecko :-(
Hi, >wine cmd /c echo yes now downloads gecko. Me to -- I'm not pleased with Wine-1.1.33 starting an installation request upon startup. - How am I going to automate regression testing when it hangs waiting for a mouse click? - I tried to think positively about it and expected the winetest-1.1.33.exe to install Gecko and perform the mshtml tests when online. Curiously they were skipped. I have yet to find out why. >Any suggestions are welcome. Winecfg would be a better place to propose the installation of an optional component. Perhaps I'm a very atypical Wine user: - no MMORPG, no ie6 - My Wine is not used for anything online. Quite to the contrary, I have some iptables firewall rules to disable Wine IP traffic should anything ever manage to get in. - I never used winetricks. I sometimes peeked at it. When I needed Gecko long ago, I saw that the Wine source contains code to install it, downloaded Gecko.cab myself, modified the one registry entry to point to the .cab and let it install. Worked. IMHO, no general-purpose application should attempt to talk to the internet when it starts. Please leave that behaviour to viruses and trojans only (and alikes, e.g. Adobe's pdf). Maybe I'm too old-fashioned in this decade of "always online even in the subway" technical achievements. Or I've been in the privacy-protection (Datenschutz) and security business for too long. Regarding winecfg, it could display "no Gecko/HTML support, click here to install it (need be online)" in flashing red to attract the user's attention once you start it. I wouldn't mind. Regards, Jörg Höhle.
Re: comctl32/listview: use the infile ImageListRelease
Nikolay Sivov schrieb:
> Hi, Andre.
>
> Could you please wait with that? I have some similar patches already sent...
>
> On 11/16/09, André Hentschel wrote:
>> Otherwise Apps crash on exit(e.g. uninstaller)
>> ---
>> dlls/comctl32/imagelist.c |3 ++-
>> 1 files changed, 2 insertions(+), 1 deletions(-)
>>
>> diff --git a/dlls/comctl32/imagelist.c b/dlls/comctl32/imagelist.c
>> index 82d2664..44084fd 100644
>> --- a/dlls/comctl32/imagelist.c
>> +++ b/dlls/comctl32/imagelist.c
>> @@ -81,6 +81,7 @@ static INTERNALDRAG InternalDrag = { 0, 0, 0, 0, 0, 0,
>> FALSE, 0 };
>>
>> static HBITMAP ImageList_CreateImage(HDC hdc, HIMAGELIST himl, UINT count,
>> UINT width);
>> static HRESULT ImageListImpl_CreateInstance(const IUnknown *pUnkOuter,
>> REFIID iid, void** ppv);
>> +static ULONG WINAPI ImageListImpl_Release(IImageList *iface);
>>
>> static inline BOOL is_valid(HIMAGELIST himl)
>> {
>> @@ -716,7 +717,7 @@ ImageList_Destroy (HIMAGELIST himl)
>> DeleteObject (himl->hbrBlend50);
>>
>> /* Free the IImageList instance */
>> -IImageList_Release((IImageList *) himl);
>> +ImageListImpl_Release((IImageList *) himl);
>> return TRUE;
>> }
>>
>> --
>>
>> Best Regards, André Hentschel
>>
>>
>>
>
>
ok, of course!
--
Best Regards, André Hentschel
Re: [PATCH 2/2] dsound: Simplify duplex code
Maarten Lankhorst writes:
> @@ -48,37 +50,20 @@ typedef struct IDirectSoundFullDuplexImpl
>
> /* IDirectSoundFullDuplexImpl fields */
> DirectSoundDevice*renderer_device;
> -DirectSoundCaptureDevice *capture_device;
> -
> -LPUNKNOWN pUnknown;
> -LPDIRECTSOUND pDS;
> -LPDIRECTSOUND8pDS8;
> -LPDIRECTSOUNDCAPTURE pDSC;
> +IDirectSoundCapture *capture_device;
> +
> +const IUnknownVtbl *lpUnkVtbl;
> +const IDirectSoundVtbl *lpDSVtbl;
> +const IDirectSound8Vtbl *lpDS8Vtbl;
> +const IDirectSoundCaptureVtbl *lpDSCVtbl;
> +LONG unk_ref;
> +LONG ds_ref;
> +LONG ds8_ref;
> +LONG dsc_ref;
> } IDirectSoundFullDuplexImpl;
>
> -typedef struct IDirectSoundFullDuplex_IUnknown {
> -const IUnknownVtbl *lpVtbl;
> -LONGref;
> -IDirectSoundFullDuplexImpl *pdsfd;
> -} IDirectSoundFullDuplex_IUnknown;
> -
> -typedef struct IDirectSoundFullDuplex_IDirectSound {
> -const IDirectSoundVtbl *lpVtbl;
> -LONGref;
> -IDirectSoundFullDuplexImpl *pdsfd;
> -} IDirectSoundFullDuplex_IDirectSound;
> -
> -typedef struct IDirectSoundFullDuplex_IDirectSound8 {
> -const IDirectSound8Vtbl*lpVtbl;
> -LONGref;
> -IDirectSoundFullDuplexImpl *pdsfd;
> -} IDirectSoundFullDuplex_IDirectSound8;
> -
> -typedef struct IDirectSoundFullDuplex_IDirectSoundCapture {
> -const IDirectSoundCaptureVtbl *lpVtbl;
> -LONG ref;
> -IDirectSoundFullDuplexImpl*pdsfd;
> -} IDirectSoundFullDuplex_IDirectSoundCapture;
> +#define ICOM_THIS_MULTI(impl,field,iface) \
> +impl* const This=(impl*)((char*)(iface) - offsetof(impl,field))
Please define inline functions instead of ICOM_THIS_MULTI. Also the
IUnknown vtable is most likely unnecessary.
--
Alexandre Julliard
julli...@winehq.org
Re: [PATCH 1/3] user32: Free window text to prevent leak in case whenWM_NCDESTROY doesn't get to default procedure
The only case why I left it was that I thought about app that directly sends this message for some insane reason. I just don't want to touch default handler. On 11/16/09, Dmitry Timoshkov wrote: > "Nikolay Sivov" wrote: > >> This fixes a leak spotted by valgrind. >> >> Changelog: >>- free window text to prevent leak in case when WM_NCDESTROY >> doesn't get to default procedure > > Then WM_NCDESTROY handler should be removed from DefWindowProc > to avoid a confusing duplication. > > -- > Dmitry. >
Re: comctl32/listview: use the infile ImageListRelease
Hi, Andre.
Could you please wait with that? I have some similar patches already sent...
On 11/16/09, André Hentschel wrote:
> Otherwise Apps crash on exit(e.g. uninstaller)
> ---
> dlls/comctl32/imagelist.c |3 ++-
> 1 files changed, 2 insertions(+), 1 deletions(-)
>
> diff --git a/dlls/comctl32/imagelist.c b/dlls/comctl32/imagelist.c
> index 82d2664..44084fd 100644
> --- a/dlls/comctl32/imagelist.c
> +++ b/dlls/comctl32/imagelist.c
> @@ -81,6 +81,7 @@ static INTERNALDRAG InternalDrag = { 0, 0, 0, 0, 0, 0,
> FALSE, 0 };
>
> static HBITMAP ImageList_CreateImage(HDC hdc, HIMAGELIST himl, UINT count,
> UINT width);
> static HRESULT ImageListImpl_CreateInstance(const IUnknown *pUnkOuter,
> REFIID iid, void** ppv);
> +static ULONG WINAPI ImageListImpl_Release(IImageList *iface);
>
> static inline BOOL is_valid(HIMAGELIST himl)
> {
> @@ -716,7 +717,7 @@ ImageList_Destroy (HIMAGELIST himl)
> DeleteObject (himl->hbrBlend50);
>
> /* Free the IImageList instance */
> -IImageList_Release((IImageList *) himl);
> +ImageListImpl_Release((IImageList *) himl);
> return TRUE;
> }
>
> --
>
> Best Regards, André Hentschel
>
>
>
Re: [PATCH] winex11.drv: check for org = NULL (Coverity)
On Mon, Nov 16, 2009 at 11:02 AM, Marcus Meissner wrote: > On Sun, Nov 15, 2009 at 10:37:27PM +0100, Roderick Colenbrander wrote: >> Hi Marcus, >> >> A couple of hours ago I submitted a patch rewrites the function. It >> suffers from the same 'issue'. This and any other wgl function are >> called from gdi32/opengl.c which perform magic to arrive here and in >> case of wglsharelists it also performs the filtering. > > Do I understand right that this is actually something we should mark > as FALSE or IGNORE in Coverity? Yeah, it can be set to ignore. Roderick
Re: [PATCH] winex11.drv: check for org = NULL (Coverity)
On Sun, Nov 15, 2009 at 10:37:27PM +0100, Roderick Colenbrander wrote:
> Hi Marcus,
>
> A couple of hours ago I submitted a patch rewrites the function. It
> suffers from the same 'issue'. This and any other wgl function are
> called from gdi32/opengl.c which perform magic to arrive here and in
> case of wglsharelists it also performs the filtering.
Do I understand right that this is actually something we should mark
as FALSE or IGNORE in Coverity?
Ciao, Marcus
> Roderick
>
> On Sun, Nov 15, 2009 at 7:28 PM, Marcus Meissner
> wrote:
> > Hi,
> >
> > Coverity spotted some inconsistencies in "org" NULL
> > checking.
> >
> > org originates via Windows code (I think) so we better check it.
> >
> > Ciao, Marcus
> > ---
> > dlls/winex11.drv/opengl.c | 8 ++--
> > 1 files changed, 6 insertions(+), 2 deletions(-)
> >
> > diff --git a/dlls/winex11.drv/opengl.c b/dlls/winex11.drv/opengl.c
> > index 45da479..774b205 100644
> > --- a/dlls/winex11.drv/opengl.c
> > +++ b/dlls/winex11.drv/opengl.c
> > @@ -1918,11 +1918,15 @@ BOOL CDECL X11DRV_wglShareLists(HGLRC hglrc1, HGLRC
> > hglrc2) {
> >
> > if (!has_opengl()) return FALSE;
> >
> > + if (NULL == org) {
> > + ERR("Could not share display lists, original context required.\n");
> > + return FALSE;
> > + }
> > if (NULL != dest && dest->ctx != NULL) {
> > - ERR("Could not share display lists, context already created !\n");
> > + ERR("Could not share display lists, context already created!\n");
> > return FALSE;
> > } else {
> > - if(org && dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^
> > (GetObjectType(dest->hdc) == OBJ_MEMDC)) {
> > + if(dest && (GetObjectType(org->hdc) == OBJ_MEMDC) ^
> > (GetObjectType(dest->hdc) == OBJ_MEMDC)) {
> > WARN("Attempting to share a context between a direct and
> > indirect rendering context, expect issues!\n");
> > }
> >
> > --
> > 1.5.6
> >
> >
> >
>
--
Working, but not speaking, for the following german company:
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nuernberg)
Re: Working on avifil32, sudden "non enough memory" error
On Mon, Nov 16, 2009 at 10:52:04AM +0100, Julius Schwartzenberg wrote:
> Dan Kegel wrote:
> >Julius wrote:
> >>With one file however (GOODTIME.AVI from the win95 cd) I get this
> >>error after about a second:
> >>err:heap:HEAP_ValidateInUseArena Heap 0x11: in-use arena 0x184420
> >>next block has PREV_FREE flag
> >>non enough memory
> >>
> >>I have no idea where this comes from and why it happens. (It appears to
> >>be unrelated to the memcpy call in avifile.c around line 1114.) With
> >>+heap I also get this before the error:
> >>HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt.
> >>(the assert fails)
> >
> >Sounds like heap corruption. You might want to cut down the
> >file to the shortest one that causes the crash, then go
> >after it (possibly using valgrind or the like) to look for
> >the error.
>
> With valgrind I was able to find the problem actually happens when
> AVIFILE_ReadBlock is called and a new block is about to be read.
> There doesn't seem to be anything special about this however, as for
> the previous blocks (and different files) it works just fine.
You could insert
HeapValidate(GetProcessHeap(),0,0);FIXME("at place x\n");
at multiple interesting places in your code and +heap will then trigger
on when the corruption happens.
Ciao, Marcus
Re: Working on avifil32, sudden "non enough memory" error
Dan Kegel wrote: Julius wrote: With one file however (GOODTIME.AVI from the win95 cd) I get this error after about a second: err:heap:HEAP_ValidateInUseArena Heap 0x11: in-use arena 0x184420 next block has PREV_FREE flag non enough memory I have no idea where this comes from and why it happens. (It appears to be unrelated to the memcpy call in avifile.c around line 1114.) With +heap I also get this before the error: HIGHPERF/GOODTIME.AVI: heap.c:403: HEAP_GetPtr: Controletest '0' faalt. (the assert fails) Sounds like heap corruption. You might want to cut down the file to the shortest one that causes the crash, then go after it (possibly using valgrind or the like) to look for the error. With valgrind I was able to find the problem actually happens when AVIFILE_ReadBlock is called and a new block is about to be read. There doesn't seem to be anything special about this however, as for the previous blocks (and different files) it works just fine. Does your implementation of avifil32 and friends work properly on windows? It appears this is not trivial to test. I had to include Wine's advapi32.dll in addition to avifil32.dll and then I got an error about a missing Wine symbol in ntdll.dll. I understand this means I cannot trivially use this Wine dll on Windows. Thanks, Julius
Re: [RFC] Extended Attributes for Dos Attributes, Creation Time, etc.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Dan Kegel wrote: > Hi Ben, > did you see > http://bugs.winehq.org/show_bug.cgi?id=15679 > http://www.winehq.org/pipermail/wine-patches/2009-October/079842.html > ? > > IMHO the way the Samba sources merged the fd and filename > version of the calls makes for less duplication of code. > (I tried to do it the other way first, and it seemed ugly.) > - Dan I saw that, and that's at least part of why I created that extended attribute portability patch for libport. Serves as one location to fix any bugs in it, or extend the support to other platforms. I noticed that the portability functions in libport were each in their own separate C file, and that's why I did it like that. I can see what you're saying about duplication of code, and it would make sense to merge the xattr portability functions into a single C file (e.g. xattr.c). If there's a better place for the xattr portability code, please say so. I know it's unlikely to be merged until a few units actually start using extended attributes. Thinking about the NT ACL storage issue (brought up by bug #20643), rather than using xattrs for that, POSIX ACLs would be a better target. -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAksBFp8ACgkQTHDAI68NsukTqQCfcFNsC+1o0YjSbBf9kHW3w0nF 2IkAnicyCrgnmqZl+Qd+DAmke+C0yHVA =ANKR -END PGP SIGNATURE- <>
