Hi Stephen,
thanks for confirming and bumping up the bug.
Yeah, getting rid of the graphical messageBox would be key.
Although personally I don't understand the reason for the whole locking
mechanism in the first place - my tests indicate that self-installing
scripted plugins living in *Application/Plugins* do not get locked that
way, for instance...
But I don't mind it at all as long as we can get rid of the messageBox(es).
By the way, my gut feeling is that this might only an issue on XP 64 - I
will try to repro on Windows 7 in a bit and will let you know.
Thanks, Martin
--
Martin Chatterjee
[ Freelance Technical Director ]
[ http://www.chatterjee.de ]
On Fri, Jun 22, 2012 at 1:26 PM, Stephen Blair
<[email protected]>wrote:
> 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 ]
>
