Hi Martin Yes, this has been reported and logged before. I repro it simply by starting many xsibatch sessions, eventually you'll get an Unable to access error. It could be for a compound, or for a toolbar, or some other file.
I'll log it again to bump it back up. At the very least, xsibatch should not display a message requiring use interaction. Stephen Blair Softimage Support Specialist Premium Support Services Autodesk, Inc. Montreal, Quebec, Canada Blog: http://xsisupport.com From: [email protected] [mailto:[email protected]] On Behalf Of Martin Chatterjee Sent: June-22-12 7:19 AM To: [email protected] Subject: workgroup access collisions - xsibatch displays graphical MessageBox waiting for user input... Hi List, hi Support, we are experiencing a bit of an annoying issue regarding access collisions on workgroups. Bear with me - it'll take a few lines to explain: When a workgroup is loaded (or refreshed from within an open Softimage session) its subdirectories get scanned and all self-installing plugins, shaders and ICE compounds get registered accordingly. During this scan Softimage will take over exclusive access for every ICE compound in /Data/Compounds. It will do this by creating a .lock file (e.g. MyCompound.xsicompound.lock) to prevent collisions. Under normal circumstances this lock file will be deleted straight after file scan and this lock should only be present for a veeery short time ( < 1ms or so...). However if a second session of Softimage tries to access a locked compound the user will get prompted by a messageBox that the compound is not accessible. He can then choose to ignore it and proceed. Through a series of VERY annoying circumnstances (dont't get me started... ) these workgroup scans are quite slow on our side right now resulting in quite a few collisions on a regular basis. And here's our problem: Even an xsibatch session (!!!!) will display the same UI messagebox and will wait until eternity for a user to interact with it. (see attached screenshot) This is on our blades running Windows XP 64 (yeah, I know...) In my humble opinion this is a bug and should be solved - a headless command line application such as xsibatch should NEVER popup graphical messageboxes and wait for user interaction... To make matters worse a xsibatch process controlled through a Renderfarm management software that exists as a windows service will not even display the bloody messagebox (as windows services cannot have desktop UI interaction). Instead the process will sit there forever with 0% CPU load waiting for a mouse klick. Just a heads up to any other poor souls out there that might have experienced this as well... And please, if anybody from Autdoesk is still reading: I'd love to get feedback if you can repro and fix this. Thanks in advance. Thanks, Martin --- REPRO STEPS: ----------- (Softimage 2012 SAP x64 @ Windows XP 64 [latest Service Packs and patches] ) 1.) link a workgroup containing an .xsicompound file in /Data/Compounds 2.) close Softimage 3.) manually create a lock file and make sure the file handle is kept open ... thereby simulating the collision. (I did this using a few lines of python code in a shell (attached to this mail - please rename to 'lockFile.py' )) --> you should now have two files in /Data/Compounds: myWickedCompound.xsicompound myWickedCompound.xsicompound.lock 4.) Try to delete the lock file by hand in the Windows Explorer --> this should NOT work as the file handle is still in use. 5.) Now start an xsibatch session - simply executing 'xsibatch' in a softimage shell without arguments should be enough. 6.) There you are - after a few secs you will be get the graphical MessageBox waiting for a mouse klick (at least on Windows XP 64) -- Martin Chatterjee [ Freelance Technical Director ] [ http://www.chatterjee.de ]
<<attachment: winmail.dat>>
