OSgrid release has just been posted, feel free to download it and give a test! http://www.osgrid.org/index.php/downloads
On Mon, Apr 29, 2013 at 7:16 PM, Dr Ramesh Ramloll <[email protected]>wrote: > Thanks so much Justin, that was fast. > > > On Mon, Apr 29, 2013 at 5:22 PM, Justin Clark-Casey < > [email protected]> wrote: > >> I was able to reproduce this bug and fix it in git master 12054aa. >> >> It looks like the bug may have been around for a very long time (perhaps >> even since June 2010) though that would be quite surprising. >> >> It would probably have affected all viewers. >> >> >> On 28/04/13 15:56, Dr Ramesh Ramloll wrote: >> >>> Thanks for pointing this critical bug out. It is surely a show stopper >>> if one is using a lot of object dispensers for >>> users ... on a sim. Looks like my obsession to keep all inventory as >>> rezzed objects and saved as an oar file is going to >>> continue for a while (might be irrational but the inventory system does >>> not look safe yet). >>> >>> >>> On Sun, Apr 28, 2013 at 12:34 AM, Chris <[email protected] <mailto: >>> [email protected]>> wrote: >>> >>> Hmm... That is a bit strange. On the viewers I thought to be OK I >>> was able to utilize the test object after the test >>> (By attempting to rez the object and looking to see if it would >>> appear or not and watching the console for errors). >>> However, I based all my tests transferring an item from Phoenix >>> viewer (which is currently my viewer of choice) to >>> the viewers in my test results since it didn't seem to make a >>> difference which viewer the item came from, just the >>> viewers they were going to. I managed to lose a script I spent about >>> 8 hours working on in the process due to the >>> Lost and Found folder issue explained toward the end of my previous >>> email (D'oh!)... but I was able to recover it by >>> grepping a dump of my database and then dumping the most recent >>> asset. >>> >>> I did a quick test as I was writing this with a transfer from >>> Firestorm to Firestorm on seperate computers and with >>> viewers on the same computer (Computer OS is running on) to be sure >>> but I was not able to reproduce the issue in >>> this way. I also tried with both HTTP Inventory on and off as well >>> but it didn't seem to make a difference. The Lost >>> and Found issue also does not show up on the viewers listed as OK in >>> my previous tests with the exception of Phoenix >>> viewer, it's OK when using silent discard, but the issue shows up >>> when using regular discard. >>> >>> As an addendum to my previous test, I also noticed that if other >>> avatars had a copy of the object you gave to >>> another avatar, and the issue is triggered, then that particular >>> object will missing from the other avatars >>> inventories as well. Just to be clear, when I say missing, I mean >>> that it seems to be missing from the database, but >>> not visually from the inventory (at least not until a relog); can't >>> do anything with the object in the way of using >>> it such as rezzing, wearing, transferring, etc. >>> >>> >>> On 4/27/2013 6:32 PM, InuYasha Meiji wrote: >>> >>> So you understand and know, I only used two viewers with two >>> different accounts on the same machine, on the same >>> machine running the grid. Both of these logged in using the >>> latest Firestorm for Opensim. Having the same >>> results as well and finding that although you see that Firestorm >>> in your list appears to be ok... >>> >>> Item Transfer -> Singularity (1.8.0) = Missing inventory item >>> Item Transfer -> Firestorm (4.4.0) = OK >>> Item Transfer -> Hippo OpenSim (0.6.3) = Missing inventory item >>> Item Transfer -> Imprudence (1.3.0) = Missing inventory item >>> Item Transfer -> Phoenix (1.6.0.1600) = Missing inventory item >>> when using normal Discard, OK when using >>> (Discard) (Silent discard) >>> Item Transfer -> Radegast (2.12.1354) = Missing inventory item >>> Item Transfer -> Kokua (3.5.1.27984) = OK >>> Item Transfer -> CoolVL (1.26.8.1) = Missing inventory item >>> >>> It really isn;t. It is only in your inventory in name, but not >>> useable, so I would not give it an ok. Thanks >>> for gonig through all the trouble of testing so many viewers to >>> prove it isn't a >>> Viewer issue. >>> >>> InuYasha >>> >>> >>> >>> >>> On 4/27/2013 2:29 PM, Chris wrote: >>> >>> Last night I tested with 2 avatars on the same machine >>> OpenSim is running on, one avatar on one machine and >>> one avatar on a different machine, and both avatars on a >>> machine other than the one OpenSim is running on. >>> >>> I repeated my tests today a bit more in depth and it would >>> seem that the issue does not depend so much on >>> the viewer the person transferring the item is using but >>> more depends on what viewer the person on the >>> receiving end of the inventory transfer is running. >>> Steps to reproduce: >>> >>> 1. Offer an item transfer to another avatar that you aren't >>> afraid to lose (Creating a new prim and taking >>> it to inventory then offering that is sufficient) >>> >>> 2. Decline the transfer on the other avatar and it should go >>> to that avatar's trash folder. >>> >>> 3. Empty that avatar's trash folder. >>> >>> 4. Go back to the first avatar and try to rez, wear, or >>> otherwise utilize the item that was to be >>> transferred (In my case I attempted to rez the object). >>> a. Should notice that it won't have any effect >>> b. Look in the console and there should be errors to >>> the effect of "item not found" >>> >>> My error when attempting to rez the object: >>> 16:11:48 - [INVENTORY ACCESS MODULE]: Could not find >>> item 6d3689ee-5c06-478d-8c10-__**10870cc6e788 for >>> >>> Test User in RezObject() >>> >>> 5. Relog the avatar you attempted item transfer from. The >>> item will be missing from their inventory upon relog. >>> Test results: >>> (Format: Item Transfer -> Viewer name of the person >>> receiving item.) >>> >>> Item Transfer -> Singularity (1.8.0) = Missing inventory item >>> Item Transfer -> Firestorm (4.4.0) = OK >>> Item Transfer -> Hippo OpenSim (0.6.3) = Missing inventory >>> item >>> Item Transfer -> Imprudence (1.3.0) = Missing inventory item >>> Item Transfer -> Phoenix (1.6.0.1600) = Missing inventory >>> item when using normal Discard, OK when using >>> (Discard) (Silent discard) >>> Item Transfer -> Radegast (2.12.1354) = Missing inventory >>> item >>> Item Transfer -> Kokua (3.5.1.27984) = OK >>> Item Transfer -> CoolVL (1.26.8.1) = Missing inventory item >>> >>> It seems like if the issue triggers, there will be two >>> copies of the declined object that will show up in >>> the receiver's trash folder. The tests also apply to >>> offering entire folders of items. It also looks like on >>> declining the transfer, If there are any other items >>> directly under neath it in the person transferring the >>> item, those items will some how wind up in the other >>> person's lost and found folder. If the person deletes >>> those items from lost and found it will remove those items >>> also from the other persons inventory. >>> >>> As far as the viewer I use; I mainly swap between Phoenix, >>> Imprudence, and Singularity. As for other users >>> on my install it could be any of the ones listed in the >>> tests (And possibly others, but these are the main >>> ones I was able to come up with). >>> >>> >>> On 4/27/2013 10:47 AM, drWhiet wrote: >>> >>> Chris, are you testing this with yourself e.g. With 2 >>> Viewers running on the Same machine ? Or are you >>> testing this behaviour with your avatar and a different >>> users Avatar ? And by the way which Viewer do >>> you (and the other user) use ?? >>> >>> Best regards, >>> >>> Am 27.04.2013 um 03:37 schrieb Chris< >>> [email protected] <mailto:[email protected]>>**: >>> >>> >>> -- >>> OpenSim: 10 Region Standalone on 0.7.6 Dev >>> Physics: Open Dynamics Engine >>> OS: Windows 7 (x64) >>> CPU: AMD Phenom II X4 840 3.2 GHz >>> Memory: 11 GB DDR3 >>> Database: MySQL 5.1.63 (x64) >>> >>> >>> ______________________________**___________________ >>> Opensim-users mailing list >>> [email protected] <mailto:Opensim-users@lists.* >>> *berlios.de <[email protected]>> >>> >>> https://lists.berlios.de/__**mailman/listinfo/opensim-users<https://lists.berlios.de/__mailman/listinfo/opensim-users> >>> >>> >>> <https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >>> **> >>> >>> >>> >>> >>> >>> -- >>> OpenSim: 10 Region Standalone on 0.7.6 Dev >>> Physics: Open Dynamics Engine >>> OS: Windows 7 (x64) >>> CPU: AMD Phenom II X4 840 3.2 GHz >>> Memory: 11 GB DDR3 >>> Database: MySQL 5.1.63 (x64) >>> >>> ______________________________**___________________ >>> Opensim-users mailing list >>> [email protected] <mailto:Opensim-users@lists.** >>> berlios.de <[email protected]>> >>> >>> https://lists.berlios.de/__**mailman/listinfo/opensim-users<https://lists.berlios.de/__mailman/listinfo/opensim-users>< >>> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >>> **> >>> >>> >>> >>> >>> >>> -- >>> 'Consider how the lilies grow. They do not labor or spin.' >>> *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate >>> /Research Associate Professor/, Idaho State University, >>> >>> Pocatello, ID 83209 Tel: 208-240-0040 >>> Blog >>> <http://deepsemaphore.**posterous.com/<http://deepsemaphore.posterous.com/>>, >>> LinkedIn >>> <http://www.linkedin.com/in/**rameshramloll<http://www.linkedin.com/in/rameshramloll>>, >>> DeepSemaphore LLC >>> <http://www.deepsemaphore.com>**, Google+ profile < >>> https://plus.google.com/**103652369558830540272/about<https://plus.google.com/103652369558830540272/about> >>> > >>> >>> >>> >>> ______________________________**_________________ >>> Opensim-users mailing list >>> [email protected] >>> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >>> >>> >> >> -- >> Justin Clark-Casey (justincc) >> OSVW Consulting >> http://justincc.org >> http://twitter.com/justincc >> >> ______________________________**_________________ >> Opensim-users mailing list >> [email protected] >> https://lists.berlios.de/**mailman/listinfo/opensim-users<https://lists.berlios.de/mailman/listinfo/opensim-users> >> > > > > -- > 'Consider how the lilies grow. They do not labor or spin.' > *Rameshsharma Ramloll* PhD, CEO CTO DeepSemaphore LLC, Affiliate *Research > Associate Professor*, Idaho State University, Pocatello, ID 83209 Tel: > 208-240-0040 > Blog <http://deepsemaphore.posterous.com/>, > LinkedIn<http://www.linkedin.com/in/rameshramloll> > , DeepSemaphore LLC <http://www.deepsemaphore.com>, Google+ > profile<https://plus.google.com/103652369558830540272/about> > > _______________________________________________ > Opensim-users mailing list > [email protected] > https://lists.berlios.de/mailman/listinfo/opensim-users > -- Michael Emory Cerquoni
_______________________________________________ Opensim-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/opensim-users
