No subject


Sat Apr 19 01:31:08 UTC 2014 

ventory to me - we did until recently have some lost assets after SI sessio=
ns due to asset server crashing - previously the code would attempt to stor=
e assets with descriptions bigger than database field length. This seemed t=
o happen mostly with SI uploaded items but also was 100% reproducible if yo=
u had a sim with a long name and a parcel with a long name and attempted to=
 create a landmark - there are checks now to stop this from happening that =
Justin kindly committed (and he was good enough to add similar checks for M=
ySQL) and we've not had a crash since applying that patch over a week and a=
 half ago. In terms of actual inventory, no-one has reported loss of specif=
ic items. Sometimes slow to load, but not loss.

Is this something that has happened since 0.6.6 tag?

Chris

-----Original Message-----
From: opensim-dev-bounces at lists.berlios.de<mailto:opensim-dev-bounces at lists=
.berlios.de> [mailto:opensim-dev-bounces at lists.berlios.de<mailto:opensim-de=
v-bounces at lists.berlios.de>] On Behalf Of Melanie
Sent: 27 July 2009 14:32
To: opensim-dev at lists.berlios.de<mailto:opensim-dev at lists.berlios.de>
Subject: Re: [Opensim-dev] Inventory loss

Those MySQL issues listed below and others like it are corner cases
that OpenSim would never trigger. OpenSim is a very simplistic
database user, it doesn't even really use any relational features of
the database.
So, I don't think that MySQL errors are something we need to concern
ourselves with at this point. Especially, your suggestion would not
help in those cases, as they are all about complete loss of rows.
That is unaffected by a "deleted" type flag.

That is neither here nor there anyway, since such a "deleted" flag
would have to live under OpenSim.Data.XXXX.

It has no business being in core at all.

Melanie


Colin B. Withers wrote:
> Reason I wondered is simply the number of websites dedicated to recoverin=
g from MYSQL database corruption, and offering tools for the same. Google r=
eturns over 250,000 sites for 'mysql database corruption'.
>
> MYSQL has had numerous bug fixes to fix database corruption, introduced b=
y differing versions of MYSQL, eg
>
> Fixed in 4.0.18
> INSERT DELAYED ... SELECT ... could cause table corruption because tables=
 were not locked properly. This is now fixed by ignoring DELAYED in this co=
ntext. (Bug #1983)
>
> Fixed in 4.0.16
> Fixed bug in overrun check for BLOB values with compressed tables. This w=
as a bug introduced in 4.0.14. It caused MySQL to regard some correct table=
s containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug =
#1295)
>
> Fixed in 4.0.15
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file header =
was not updated directly after an UPDATE of split dynamic rows. The symptom=
 was that the table had a corrupted delete-link if mysqld was shut down or =
the table was checked directly after the update.
>
> Fixed in 4.0.14
> Comparison/sorting for latin1_de character set was rewritten. The old alg=
orithm could not handle cases like "s=E4" < "=DFa". See section 5.6.1.1 Ger=
man character set. In rare cases, it resulted in table corruption.
>
> and so on..
>
> My own experience with Opensim is that in the last 12 months there has be=
en three occasions where residents complained of stuff 'missing' (not a sin=
gle resident, but several at once) and a roll-back to the last database bac=
kup cured the problems.
>
> Rock
>
> -----Original Message-----
> From: opensim-dev-bounces at lists.berlios.de<mailto:opensim-dev-bounces at lis=
ts.berlios.de> [mailto:opensim-dev-bounces at lists.berlios.de<mailto:opensim-=
dev-bounces at lists.berlios.de>] On Behalf Of Melanie
> Sent: Monday, July 27, 2009 2:07 PM
> To: opensim-dev at lists.berlios.de<mailto:opensim-dev at lists.berlios.de>
> Subject: Re: [Opensim-dev] Inventory loss
>
> IMHO, inventory loss due to MySQL errors and/or corruption are below
> the radar.
> Any losses would occur in OpenSim code, I believe.
>
> Melanie
>
> Colin B. Withers wrote:
>> I wonder what proportion of inventory items that go astray are the resul=
t of the success/failure of an operation, or are due to database corruption=
 issues.
>>
>> Rock
>>
>> -----Original Message-----
>> From: opensim-dev-bounces at lists.berlios.de<mailto:opensim-dev-bounces at li=
sts.berlios.de> [mailto:opensim-dev-bounces at lists.berlios.de<mailto:opensim=
-dev-bounces at lists.berlios.de>] On Behalf Of Melanie
>> Sent: Monday, July 27, 2009 12:30 PM
>> To: opensim-dev at lists.berlios.de<mailto:opensim-dev at lists.berlios.de>
>> Subject: Re: [Opensim-dev] Inventory loss
>>
>> There is a question here of why inventory loss occurs at all. At
>> what stage do we actually lose (as opposed to failing to bump the
>> folder serial) inventory items at all, and why?
>>
>> While a "deleted" flag and an undelete function do make an admin's
>> life easier, I believe the real focus should be on the inventory
>> code. It will be redesigned anyway and once that happens, I think a
>> strong focus needs to be placed on data integrity preservation.
>>
>> That would then mae the undelete functionality largely unnecessary.
>> Current inventory code often doesn't check for success of an
>> operation at all. That needs to be revisited.
>>
>> Melanie
>>
>> Thomas Grimshaw wrote:
>>> Hey folks.
>>>
>>> Been thinking a lot about inventory loss in OpenSim, something that I
>>> think we should really do as much as possible to avoid. We've been
>>> experiencing numerous cases of lost inventory in K-Grid recently.
>>>
>>> What i'd like to implement, is..
>>>
>>> When an item is removed from inventory (deleted, or rezzed if it's
>>> no-copy), it is not actually deleted by instead an "available" flag is
>>> set in the inventory database.
>>> All inventory queries will check for the flag and thus it will appear a=
s
>>> deleted to the user, but it can be restored easily by an admin if
>>> needed.  A timestamp should also be set which indicates when the item
>>> was made unavailable, so that routine cleanup can be performed on items
>>> which were made unavailable a long time ago.
>>>
>>> I wanted to get people's opinons of this before I implemented it in
>>> code. Can anyone think of any drawbacks or possible issues? Any further
>>> room for improvement?
>>>
>>> Cheers
>>>
>>> Thomas Grimshaw
>>> (RemedyTomm)
>>> _______________________________________________
>>> Opensim-dev mailing list
>>> Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
>>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>>
>>>
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>> _______________________________________________
>> Opensim-dev mailing list
>> Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
>> https://lists.berlios.de/mailman/listinfo/opensim-dev
>>
>>
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
> _______________________________________________
> Opensim-dev mailing list
> Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
> https://lists.berlios.de/mailman/listinfo/opensim-dev
>
>

_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev
No virus found in this incoming message.
Checked by AVG - www.avg.com<http://www.avg.com>
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09 =
05:58:00
_______________________________________________
Opensim-dev mailing list
Opensim-dev at lists.berlios.de<mailto:Opensim-dev at lists.berlios.de>
https://lists.berlios.de/mailman/listinfo/opensim-dev



--
Michael Emory Cerquoni - Nebadon Izumi @ http://osgrid.org

--_000_63FAD4F222230A4EA79DE9E8BE664735340F0360winxbeus19excha_
Content-Type: text/html; charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<META HTTP-EQUIV=3D"Content-Type" CONTENT=3D"text/html; charset=3Diso-8859-=
1">
<html xmlns:v=3D"urn:schemas-microsoft-com:vml" xmlns:o=3D"urn:schemas-micr=
osoft-com:office:office" xmlns:w=3D"urn:schemas-microsoft-com:office:word" =
xmlns:m=3D"http://schemas.microsoft.com/office/2004/12/omml" xmlns=3D"http:=
//www.w3.org/TR/REC-html40">

<head>

<meta name=3DGenerator content=3D"Microsoft Word 12 (filtered medium)">
<style>
<!--
 /* Font Definitions */
 @font-face
	{font-family:"Cambria Math";
	panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
	{font-family:Calibri;
	panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
	{font-family:Tahoma;
	panose-1:2 11 6 4 3 5 4 4 2 4;}
 /* Style Definitions */
 p.MsoNormal, li.MsoNormal, div.MsoNormal
	{margin:0cm;
	margin-bottom:.0001pt;
	font-size:12.0pt;
	font-family:"Times New Roman","serif";}
a:link, span.MsoHyperlink
	{mso-style-priority:99;
	color:blue;
	text-decoration:underline;}
a:visited, span.MsoHyperlinkFollowed
	{mso-style-priority:99;
	color:purple;
	text-decoration:underline;}
span.EmailStyle17
	{mso-style-type:personal-reply;
	font-family:"Calibri","sans-serif";
	color:#1F497D;}
.MsoChpDefault
	{mso-style-type:export-only;}
@page Section1
	{size:612.0pt 792.0pt;
	margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.Section1
	{page:Section1;}
-->
</style>
<!--[if gte mso 9]><xml>
 <o:shapedefaults v:ext=3D"edit" spidmax=3D"1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
 <o:shapelayout v:ext=3D"edit">
  <o:idmap v:ext=3D"edit" data=3D"1" />
 </o:shapelayout></xml><![endif]-->
</head>

<body lang=3DEN-AU link=3Dblue vlink=3Dpurple>

<div class=3DSection1>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>It’s worth also noting the clientside inventory skelet=
on can get
corrupted – clearing cache will often restore supposedly missing inve=
ntory.<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'>Adam<o:p></o:p></span></p>

<p class=3DMsoNormal><span style=3D'font-size:11.0pt;font-family:"Calibri",=
"sans-serif";
color:#1F497D'><o:p> </o:p></span></p>

<div style=3D'border:none;border-left:solid blue 1.5pt;padding:0cm 0cm 0cm =
4.0pt'>

<div>

<div style=3D'border:none;border-top:solid #B5C4DF 1.0pt;padding:3.0pt 0cm =
0cm 0cm'>

<p class=3DMsoNormal><b><span lang=3DEN-US style=3D'font-size:10.0pt;font-f=
amily:
"Tahoma","sans-serif"'>From:</span></b><span lang=3DEN-US style=3D'font-siz=
e:10.0pt;
font-family:"Tahoma","sans-serif"'> opensim-dev-bounces at lists.berlios.de
[mailto:opensim-dev-bounces at lists.berlios.de] <b>On Behalf Of </b>Nebadon I=
zumi<br>
<b>Sent:</b> Monday, 27 July 2009 10:39 PM<br>
<b>To:</b> opensim-dev at lists.berlios.de<br>
<b>Subject:</b> Re: [Opensim-dev] Inventory loss<o:p></o:p></span></p>

</div>

</div>

<p class=3DMsoNormal><o:p> </o:p></p>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>I don't recall OSgrid r=
eally
getting many complaints about it either, infact i do not recall any, I am n=
ot
saying its never occured, but its so minimal its not something i ever remem=
ber
occuring, even when our whole asset table corrupted, we were able to get 10=
0%
recovery, i think we lost 1 asset. We run on MySQL, but run fragstore for b=
lob
storage, any grids still storing blobs inside the database is going to be i=
n
major trouble if they don't switch, storing blobs inside of any of the
currently available database systems OpenSim's core is really a terrible id=
ea
and should not be done for anything that is considered a production level t=
ype
grid.<br>
<br>
Neb<o:p></o:p></p>

<div>

<p class=3DMsoNormal>On Mon, Jul 27, 2009 at 6:39 AM, Chris Hart <<a
href=3D"mailto:Chris at codetorque.co.uk">Chris at codetorque.co.uk</a>> wrote=
:<o:p></o:p></p>

<p class=3DMsoNormal>From MSSQL side of the grid fence, I haven't had anyon=
e
complain of lost inventory to me - we did until recently have some lost ass=
ets
after SI sessions due to asset server crashing - previously the code would
attempt to store assets with descriptions bigger than database field length=
.
This seemed to happen mostly with SI uploaded items but also was 100%
reproducible if you had a sim with a long name and a parcel with a long nam=
e
and attempted to create a landmark - there are checks now to stop this from
happening that Justin kindly committed (and he was good enough to add simil=
ar
checks for MySQL) and we've not had a crash since applying that patch over =
a
week and a half ago. In terms of actual inventory, no-one has reported loss=
 of
specific items. Sometimes slow to load, but not loss.<br>
<br>
Is this something that has happened since 0.6.6 tag?<br>
<br>
Chris<o:p></o:p></p>

<div>

<p class=3DMsoNormal><br>
-----Original Message-----<br>
From: <a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">opensim-dev-b=
ounces at lists.berlios.de</a>
[mailto:<a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">opensim-dev=
-bounces at lists.berlios.de</a>]
On Behalf Of Melanie<o:p></o:p></p>

</div>

<div>

<div>

<p class=3DMsoNormal style=3D'margin-bottom:12.0pt'>Sent: 27 July 2009 14:3=
2<br>
To: <a href=3D"mailto:opensim-dev at lists.berlios.de">opensim-dev at lists.berli=
os.de</a><br>
Subject: Re: [Opensim-dev] Inventory loss<br>
<br>
Those MySQL issues listed below and others like it are corner cases<br>
that OpenSim would never trigger. OpenSim is a very simplistic<br>
database user, it doesn't even really use any relational features of<br>
the database.<br>
So, I don't think that MySQL errors are something we need to concern<br>
ourselves with at this point. Especially, your suggestion would not<br>
help in those cases, as they are all about complete loss of rows.<br>
That is unaffected by a "deleted" type flag.<br>
<br>
That is neither here nor there anyway, since such a "deleted" fla=
g<br>
would have to live under OpenSim.Data.XXXX.<br>
<br>
It has no business being in core at all.<br>
<br>
Melanie<br>
<br>
<br>
Colin B. Withers wrote:<br>
> Reason I wondered is simply the number of websites dedicated to recove=
ring
from MYSQL database corruption, and offering tools for the same. Google ret=
urns
over 250,000 sites for 'mysql database corruption'.<br>
><br>
> MYSQL has had numerous bug fixes to fix database corruption, introduce=
d by
differing versions of MYSQL, eg<br>
><br>
> Fixed in 4.0.18<br>
> INSERT DELAYED ... SELECT ... could cause table corruption because tab=
les
were not locked properly. This is now fixed by ignoring DELAYED in this
context. (Bug #1983)<br>
><br>
> Fixed in 4.0.16<br>
> Fixed bug in overrun check for BLOB values with compressed tables. Thi=
s
was a bug introduced in 4.0.14. It caused MySQL to regard some correct tabl=
es
containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug #1=
295)<br>
><br>
> Fixed in 4.0.15<br>
> Fixed rare bug in MYISAM introduced in 4.0.3 where the index file head=
er
was not updated directly after an UPDATE of split dynamic rows. The symptom=
 was
that the table had a corrupted delete-link if mysqld was shut down or the t=
able
was checked directly after the update.<br>
><br>
> Fixed in 4.0.14<br>
> Comparison/sorting for latin1_de character set was rewritten. The old
algorithm could not handle cases like "s=E4" < "=DFa&quot=
;. See
section 5.6.1.1 German character set. In rare cases, it resulted in table
corruption.<br>
><br>
> and so on..<br>
><br>
> My own experience with Opensim is that in the last 12 months there has
been three occasions where residents complained of stuff 'missing' (not a
single resident, but several at once) and a roll-back to the last database
backup cured the problems.<br>
><br>
> Rock<br>
><br>
> -----Original Message-----<br>
> From: <a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">opensim-=
dev-bounces at lists.berlios.de</a>
[mailto:<a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">opensim-dev=
-bounces at lists.berlios.de</a>]
On Behalf Of Melanie<br>
> Sent: Monday, July 27, 2009 2:07 PM<br>
> To: <a href=3D"mailto:opensim-dev at lists.berlios.de">opensim-dev at lists.=
berlios.de</a><br>
> Subject: Re: [Opensim-dev] Inventory loss<br>
><br>
> IMHO, inventory loss due to MySQL errors and/or corruption are below<b=
r>
> the radar.<br>
> Any losses would occur in OpenSim code, I believe.<br>
><br>
> Melanie<br>
><br>
> Colin B. Withers wrote:<br>
>> I wonder what proportion of inventory items that go astray are the
result of the success/failure of an operation, or are due to database
corruption issues.<br>
>><br>
>> Rock<br>
>><br>
>> -----Original Message-----<br>
>> From: <a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">open=
sim-dev-bounces at lists.berlios.de</a>
[mailto:<a href=3D"mailto:opensim-dev-bounces at lists.berlios.de">opensim-dev=
-bounces at lists.berlios.de</a>]
On Behalf Of Melanie<br>
>> Sent: Monday, July 27, 2009 12:30 PM<br>
>> To: <a href=3D"mailto:opensim-dev at lists.berlios.de">opensim-dev at li=
sts.berlios.de</a><br>
>> Subject: Re: [Opensim-dev] Inventory loss<br>
>><br>
>> There is a question here of why inventory loss occurs at all. At<b=
r>
>> what stage do we actually lose (as opposed to failing to bump the<=
br>
>> folder serial) inventory items at all, and why?<br>
>><br>
>> While a "deleted" flag and an undelete function do make =
an
admin's<br>
>> life easier, I believe the real focus should be on the inventory<b=
r>
>> code. It will be redesigned anyway and once that happens, I think =
a<br>
>> strong focus needs to be placed on data integrity preservation.<br=
>
>><br>
>> That would then mae the undelete functionality largely unnecessary=
.<br>
>> Current inventory code often doesn't check for success of an<br>
>> operation at all. That needs to be revisited.<br>
>><br>
>> Melanie<br>
>><br>
>> Thomas Grimshaw wrote:<br>
>>> Hey folks.<br>
>>><br>
>>> Been thinking a lot about inventory loss in OpenSim, something
that I<br>
>>> think we should really do as much as possible to avoid. We've =
been<br>
>>> experiencing numerous cases of lost inventory in K-Grid recent=
ly.<br>
>>><br>
>>> What i'd like to implement, is..<br>
>>><br>
>>> When an item is removed from inventory (deleted, or rezzed if =
it's<br>
>>> no-copy), it is not actually deleted by instead an
"available" flag is<br>
>>> set in the inventory database.<br>
>>> All inventory queries will check for the flag and thus it will
appear as<br>
>>> deleted to the user, but it can be restored easily by an admin=
 if<br>
>>> needed.  A timestamp should also be set which indicates w=
hen
the item<br>
>>> was made unavailable, so that routine cleanup can be performed=
 on
items<br>
>>> which were made unavailable a long time ago.<br>
>>><br>
>>> I wanted to get people's opinons of this before I implemented =
it
in<br>
>>> code. Can anyone think of any drawbacks or possible issues? An=
y
further<br>
>>> room for improvement?<br>
>>><br>
>>> Cheers<br>
>>><br>
>>> Thomas Grimshaw<br>
>>> (RemedyTomm)<br>
>>> _______________________________________________<br>
>>> Opensim-dev mailing list<br>
>>> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at li=
sts.berlios.de</a><br>
>>> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-d=
ev"
target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>=
<br>
>>><br>
>>><br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.=
berlios.de</a><br>
>> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev"
target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>=
<br>
>> _______________________________________________<br>
>> Opensim-dev mailing list<br>
>> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.=
berlios.de</a><br>
>> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev"
target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>=
<br>
>><br>
>><br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berl=
ios.de</a><br>
> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev"
target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>=
<br>
> _______________________________________________<br>
> Opensim-dev mailing list<br>
> <a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berl=
ios.de</a><br>
> <a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev"
target=3D"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a>=
<br>
><br>
><br>
<br>
_______________________________________________<br>
Opensim-dev mailing list<br>
<a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.d=
e</a><br>
<a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" target=3D=
"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><o:p></o:=
p></p>

</div>

</div>

<p class=3DMsoNormal>No virus found in this incoming message.<br>
Checked by AVG - <a href=3D"http://www.avg.com" target=3D"_blank">www.avg.c=
om</a><br>
Version: 8.5.392 / Virus Database: 270.13.29/2261 - Release Date: 07/27/09
05:58:00<o:p></o:p></p>

<div>

<div>

<p class=3DMsoNormal>_______________________________________________<br>
Opensim-dev mailing list<br>
<a href=3D"mailto:Opensim-dev at lists.berlios.de">Opensim-dev at lists.berlios.d=
e</a><br>
<a href=3D"https://lists.berlios.de/mailman/listinfo/opensim-dev" target=3D=
"_blank">https://lists.berlios.de/mailman/listinfo/opensim-dev</a><o:p></o:=
p></p>

</div>

</div>

</div>

<p class=3DMsoNormal><br>
<br clear=3Dall>
<br>
-- <br>
Michael Emory Cerquoni - Nebadon Izumi @ <a href=3D"http://osgrid.org">http=
://osgrid.org</a><o:p></o:p></p>

</div>

</div>

</body>

</html>

--_000_63FAD4F222230A4EA79DE9E8BE664735340F0360winxbeus19excha_--

More information about the Opensim-dev mailing list