Re: RE: 0.2.4pre2

--===============57924483017581174==
Content-Type: multipart/signed; micalg=pgp-sha1;
	protocol="application/pgp-signature"; boundary="DEueqSqTbz/jWVG1"
Content-Disposition: inline


--DEueqSqTbz/jWVG1
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On Mon Sep 29, 2003 at 10:06:18AM -0700, Scott Brown wrote:

> Everything is looking super in 0.2.4pre2.

Awesome!

> Everything I have tested so far, which includes the issues we ran into on=
=20
> Friday, seems to be just fine, cc emails are going out as expected, etc...

Good.

> I think there may be a couple of things related to the Windows vs. *nix=
=20
> paths that are a little wacky, but I think I can deal with them.
>=20
> The full path info in the email was coming from this line (after checking=
=20
> out the patch and such, I puzzled it out):
>=20
> -    $stmpfile =3D ereg_replace($_CONF['shadowdir'] . "/","",$tmpfile);
>=20
> The slash is going the wrong direction for Windows, so it never catches i=
t.=20
> I tried changing it to "\", which of course didn't work, since "\" is an=
=20
> escape character, so I tried "\\" for the heck of it, and that didn't wor=
k,=20
> either. In the end, I changed the line to this:
>=20
> -    $stmpfile =3D ereg_replace($_CONF['shadowdir'] ,"",$tmpfile);

Can you try a triple slash?  Ie. try \\\ and see if that works?  One thing I
can try doing is a determination of the host OS (I'll have to look into
this).  Ie. something like "if php_os =3D "WIN" slash =3D "\\\" else slash =
=3D "/"
and then use $slash in the ereg_replace.  But I'd like to know if \\\ works;
being a perfectionist, I'd like to see the output identical on windows or
nix.

> Stopping it from looking for the trailing slash, be it forward or backwar=
d,=20
> which solved the problem! I can live with the slash in front of the file=
=20
> name. It comes out in the email like this now:
>=20
> --- 2	2003-09-29 09:47:22.000000000 -0700
> +++ \2.t766.tmp	2003-09-29 09:48:52.000000000 -0700
> @@ -43,3 +43,7 @@
>=20
> Which is totally acceptable, and for some reason, seems to have cured the=
=20
> time interpretation issue, as you can see, the time is just fine now.=20
> Earlier tests this morning were not. Yay!

Excellent.  Please try the triple \ and see if that works.  I'd like to see
that leading \ removed if possible.

> Thanks so much for all of your help!

You're welcome!

> I will keep you updated on anything I run into along the way!
>=20
> Also, so you know, I started completely from scratch this morning with=20
> 0.2.4pre2, and dropped the database I had been using, in favor of creatin=
g=20
> a brand new one, using sql.dump from the 0.2.4pre2 release. This is=20
> completely, 100% a fresh 0.2.4pre2 install!

Sounds good.  I do plan on the 0.2.4 release this week; I'm waiting for a
few translations, but I think irregardless I'll be putting 0.2.4 out
tomorrow, so any hammering you can do today would be extremely helpful.

--=20
MandrakeSoft Security; http://www.mandrakesecure.net/
Online Security Resource Book; http://linsec.ca/
"lynx -source http://linsec.ca/vdanen.asc | gpg --import"
{FE6F2AFD : 88D8 0D23 8D4B 3407 5BD7  66F9 2043 D0E5 FE6F 2AFD}


--DEueqSqTbz/jWVG1
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.3 (Darwin)

iD8DBQE/eHrAIEPQ5f5vKv0RAjlUAJ9+h9EDQWBV/b8gDttP9dq1eJ3tWwCdHUsK
TkCCtg6+oTtt+LAx2fveu74=
=+P+J
-----END PGP SIGNATURE-----

--DEueqSqTbz/jWVG1--


--===============57924483017581174==
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline

_______________________________________________
Anthill-users mailing list
Anthill-users-+mQDA36h6dWw5LPnMra/[email protected]
http://vmlinuz.ca/mailman/listinfo/anthill-users

--===============57924483017581174==--