Stephen, just a quick follow-up:
My tests indicate that the xsibatch under Windows 7 does NOT pop up these
messageBoxes.
Instead it logs a reasonable error to the console and proceeds:
*Unable to access E:\ReproWorkgroup\Data\Compounds\mch_Rpro.xsicompound*
*Another process is currently using it.*
So the problem appears to affect "only" xsibatch on Windows XP. I wonder
what makes xsibatch behave differently depending on the host OS - it's the
same executable after all...
Cheers, Martin
--
Martin Chatterjee
[ Freelance Technical Director ]
[ http://www.chatterjee.de ]
On Fri, Jun 22, 2012 at 1:50 PM, Sandy Sutherland <
[email protected]> wrote:
> We do not have this here - our setup is Win7 64 workstations with FC15
> Farm nodes.
>
> S.
>
> _____________________________
> Sandy Sutherland
> Technical Supervisor
> [email protected]
> _____________________________
>
>
>
>
> ------------------------------
> *From:* [email protected] [
> [email protected]] on behalf of Martin Chatterjee [
> [email protected]]
> *Sent:* 22 June 2012 13:36
> *To:* [email protected]
> *Subject:* Re: workgroup access collisions - xsibatch displays graphical
> MessageBox waiting for user input...
>
> 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 ]
>>
>
>
