If the fix proves okay then it should be fairly easy to port. Also, I hope to get rolling on 0.7.6 fairly soon.
On 30/04/13 22:34, ssm2017 wrote:
hello do you plan to fix the 0.7.5-post-fixes version for this bug ? 2013/4/30 Nebadon Izumi <[email protected] <mailto:[email protected]>> 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] <mailto:[email protected]>> wrote: Thanks so much Justin, that was fast. On Mon, Apr 29, 2013 at 5:22 PM, Justin Clark-Casey <[email protected] <mailto:[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]> <mailto:[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]> <mailto:[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:[email protected]> <mailto:Opensim-users@lists.__berlios.de <mailto:[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:[email protected]> <mailto:Opensim-users@lists.__berlios.de <mailto:[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 <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] <mailto:[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] <mailto:[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 <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] <mailto:[email protected]> https://lists.berlios.de/mailman/listinfo/opensim-users -- Michael Emory Cerquoni _______________________________________________ Opensim-users mailing list [email protected] <mailto:[email protected]> https://lists.berlios.de/mailman/listinfo/opensim-users _______________________________________________ Opensim-users mailing list [email protected] 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
