Close other programs before commiting content.

jeffmorris

Active member
I found out that if you use other programs like 3DS MAX, image editors, file managers, etc, to work on content, and don't close those programs, TANE will stop responding when you try to commit content. Is this a bug?
 
I found out that if you use other programs like 3DS MAX, image editors, file managers, etc, to work on content, and don't close those programs, TANE will stop responding when you try to commit content. Is this a bug?

Yes, it's a bug. Not quite what you are reporting, but pretty close. The issue is that if some other product is preventing TANE from modifying the files that you tell it to modify, it will continually retry rather than giving up and reporting an error. To reiterate: having other programs running does not cause problems, but having other programs locking TANE files/folders will trigger this issue.

thanks,

chris
 
So basic Windows (or OS?) behavior: Only one application can have change rights to one file at the same time.
 
I found that out the hard way too with a text editor I had open. I thought I had closed a file but did not and everything sat their looking at me dumbfounded until I closed the editor then everything closed quite quickly. :)

I found that if I need to keep another application open, it's okay to do so if the application isn't sitting on the edited content's open folder.

Thank you, Chris for snagging this little bug and hope to see the resolution in the future.

John
 
I do recall that with TRS2012 that even if you had a notepad file still open (config to be precise) that it would be able to commit it with no issue.
 
I do recall that with TRS2012 that even if you had a notepad file still open (config to be precise) that it would be able to commit it with no issue.

That's correct. T:ANE however sits on the folders and is unable to commit (submit) the assets, which is the problem being addressed.

John
 
So basic Windows (or OS?) behavior: Only one application can have change rights to one file at the same time.

Yeah, it's a Windows behaviour. Our bug though.

The issue is this:

1. Windows doesn't allow multiple processes to access the same part of the file system at the same time. (Many other OSes don't have this restriction. Some versions of Windows Server don't have this restriction either.)

2. Certain common windows utilities such as virus checkers open files "at random."

3. Because of #1, this can cause file operations to fail "at random".

4. We work around #3 by retrying failed operations. The retry is supposed to eventually time out, under the assumption that the virus checker won't take more than a few seconds to do its thing.


Our bug is that the retry does not always time out correctly.

chris
 
Back
Top