ooo - just noticed one more thing - once you hit cancel and xsi
decides to move on it deleted the .filethatisinuse.lock file. Weird
huh?
also not sure if I mentioned but it's a whole host of files that
generate this error - pretty much everything XSI looks up. recent
files, layout, etc.
Cheers,
Alan.
On 11/2/06, Alan Jones <skyphyr(at)gmail.com> wrote:
On 11/2/06, Joe Laffey <joe(at)laffey.tv> wrote:
> On Thu, 2 Nov 2006, Alan Jones wrote:
>
> > I don't think the file is actually locked - it seems to be that XSI
> > creates a file to tell if it's locked and then doesn't realised it's
> > XSI that created it.
> >
> > Every other application is running really nicely - purely an XSI problem
> > here.
>
> A, OK. I see what you mean. Have you studied the contents of the lockfile?
> Maybe that would tell you something? (Like what XSI stores.)
Good idea. I tried it an interestingly enough it's completely empty -
0 bytes and all. It has the correct timestamp on it and ownership.
I've tried deleting it and hitting retry and it instantly gets
recreated and the same error is thrown. Just for a laugh I also ran a
chmod 777 on it and hit retry. This is where it gets where XSI through
the same error, but it also altered the permissions.
>
> I would be ntereste in earing your solution when you find it ;-)
me too :-) will be sure to pass the details on.
Cheers,
Alan.
---
Unsubscribe? Mail Majordomo(at)Softimage.COM with the following text in body:
unsubscribe xsi
