Jon, was just reading the jabber logs of your conversation with mental wrt to this, and if i got what you were saying it sounded like the fix you were proposing was reverting to the svgz extension rather than using libxml's internal routines. I'm pretty much certain that that course of action would completely break svgz on windows, as the extension requires gzip which isnt available on 99% of peoples windows boxes. Not sure quite what the evilness is of the code in question is, but unless its very clearly breaking things for people right now I'd let it wait until 0.42. btw, we dont rely on an external gzip binary on windows, we use the zlib dll, the problem we'd had was due to the libxml dll not being linked with the optons to use the zlib. I've tried getting the gzip route used int the inx to work and its pure unadulterated evil, as the extensions code has hardcoded linux style temp filenames in it. this is a potential issue for a bunch of extension related stuff. (src\extensions\script.cpp if anyones interested) Its been on my list of things to do some testing with, I just havent got round ot it.
Cheers
John
--- "Jon A. Cruz" <jon@...18...> wrote:
Well... I went on a last-minute search for file naughtiness. There are a few pixbuf loads here and there, but I'll ignore them for now.
The one I am concerned about is in repr-io.cpp, in sp_repr_read_file
I *think* that's the last main one, but is a biggie, so I'm going to try to munge things in. Of course, this is very sensitive stuff, so it will need verifying to ensure all is happy-happy everywhere.
__________________________________ Do you Yahoo!? The all-new My Yahoo! - Get yours free! http://my.yahoo.com