applescript error handling? tmp file reference?

[James Roberts]

Attachments :You can step through and see how things look at each stage of the execution, also gives you some great error messages . Maybe helpful. James Robertsexjimmyr@gmail.com"Nothing travels faster than the speed of light, with the possible exception ofbad news, which obeys its own set of laws" ~ Douglas Adams On 09-05-2013, at 15:47 , treeceg <photo@4miledesign.com> wrote:   No, I have not. I'll take a look at it, but it's not a bug in the script per-se. --- In gcmac@yahoogroups.com, "Jim Roberts" <exjimmyr@...> wrote: > > Have you tried Script Debugger? I believe there is a trial version > > > http://www.latenightsw.com/sd5/whats-ne ... ebugger-5/ > a�€" > Sent from Mailbox for iPhone > > On Thu, May 9, 2013 at 12:15 PM, treeceg <photo@...> wrote: > > > I have a mix of 10.7 and 10.8 running. I am not using folder actions or mail rules. > > The issue is within a single 'set file iptc' instruction to GC. It creates a temp file to write the changes into, and then it replaces the original file and deletes the temp file, all from that one GC command. The error is contained within, between creating the temp file and deleting it. Since I have no control over the timing of those events within that command, it's difficult to detect a problem at any one step and deal with it. > > Greg > > --- In gcmac@yahoogroups.com, James Roberts <exjimmyr@> wrote: > >> > >> Sorry for jumping in, > >> > >> What version of OS X are you using on the machines that show inconsistent results. All my ML machines have flakey results with folder actions and mail rules (flakier than SL or L that is . The logs are full of time outs and deny reads. I know thats not much help but it may have little to do with GC. > >> > >> James Roberts > >> exjimmyr@ > >> > >> "Nothing travels faster than the speed of light, with the possible exception of > >> bad news, which obeys its own set of laws" ~ Douglas Adams > >> > >> > >> > >> > >> On 09-05-2013, at 10:43 , treeceg <photo@> wrote: > >> > >> > I'm happy to run tests for you, but I'm seeing that it's not consistent. A file that errors out, can be run back through another time, and won't create an error. It is not a high percentage of errors, but with the error point being contained within a single GC command, I am having a hard time recovering from it automatically when it does happen. > >> > > >> > I am guessing that the variable nature is due to the files residing on a server, rather than the local disk, and so Finder response times are more variable. > >> > > >> > One of my machines is running 8.6 build 1203, and it seems to recover from it better on it's own, than version 8.2 which is what I have running in production, but is creating a bunch of temp files on the desktop, which is challenging to clean up as well. > >> > > >> > Greg > >> > > >> > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > >> > > > >> > > Hello, > >> > > > >> > > hmm, maybe I can add a delay to my source and try to rewrite the file. Can we try that? > >> > > > >> > > Thorsten > >> > > > >> > > On 08.05.2013, at 21:12, "treeceg" <photo@> wrote: > >> > > > >> > > > So you have a delay built in already, and if FInder takes longer than that delay to do it's thing, then I can expect that message, and there's really nothing I can do about it. Is that accurate? When I got that message in the console, the gc_ temp file was locked open by GC, so it was harder to clean up after. > >> > > > > >> > > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > >> > > > > > >> > > > > Hello, > >> > > > > > >> > > > > I have to create a temporary file to write the new file with changes. I exchange both after that. Sometimes the file manager seems to be to slow. > >> > > > > > >> > > > > I added already a delay in the delete command if it does fail. > >> > > > > > >> > > > > Thorsten > >> > > > > > >> > > > > On 08.05.2013, at 08:41, "treeceg" <photo@> wrote: > >> > > > > > >> > > > > > So, if the file in question is both created and deleted as part of a single 'set file iptc' command, how can I control that? GC would be the one that has the file busy. > >> > > > > > > >> > > > > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > >> > > > > > > > >> > > > > > > Hi, > >> > > > > > > . > >> > > > > > > >> > > > > > > >> > > > >> > > >> > > >> >

[thorstenlemke]

Hello,I released a new beta.Please check:http://www.lemkesoft.org/beta.htmlIt does now delay and retry the write upon an error.RegardsThorsten On 09.05.2013, at 16:43, treeceg <photo@4miledesign.com> wrote:   I'm happy to run tests for you, but I'm seeing that it's not consistent. A file that errors out, can be run back through another time, and won't create an error. It is not a high percentage of errors, but with the error point being contained within a single GC command, I am having a hard time recovering from it automatically when it does happen. I am guessing that the variable nature is due to the files residing on a server, rather than the local disk, and so Finder response times are more variable. One of my machines is running 8.6 build 1203, and it seems to recover from it better on it's own, than version 8.2 which is what I have running in production, but is creating a bunch of temp files on the desktop, which is challenging to clean up as well. Greg --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hello, > > hmm, maybe I can add a delay to my source and try to rewrite the file. Can we try that? > > Thorsten

[treeceg]

Thanks, Thorsten. I'll give this a try and let you know how it goes. Greg --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hello, > > I released a new beta. > Please check: > http://www.lemkesoft.org/beta.html > > It does now delay and retry the write upon an error. > > Regards > Thorsten > > On 09.05.2013, at 16:43, treeceg <photo@...> wrote: > > > I'm happy to run tests for you, but I'm seeing that it's not consistent. A file that errors out, can be run back through another time, and won't create an error. It is not a high percentage of errors, but with the error point being contained within a single GC command, I am having a hard time recovering from it automatically when it does happen. > > > > I am guessing that the variable nature is due to the files residing on a server, rather than the local disk, and so Finder response times are more variable. > > > > One of my machines is running 8.6 build 1203, and it seems to recover from it better on it's own, than version 8.2 which is what I have running in production, but is creating a bunch of temp files on the desktop, which is challenging to clean up as well. > > > > Greg > > > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > > > > > > Hello, > > > > > > hmm, maybe I can add a delay to my source and try to rewrite the file. Can we try that? > > > > > > Thorsten >

[treeceg]

With the behavior change you made, Thorsten, at what point in that sequence does it now write the original and modified files to the desktop? Does it delay and retry once, and then write out the files if the retry fails? Greg --- In gcmac@yahoogroups.com, "treeceg" <photo@...> wrote: > > > Thanks, Thorsten. I'll give this a try and let you know how it goes. > > Greg > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > > > > Hello, > > > > I released a new beta. > > Please check: > > http://www.lemkesoft.org/beta.html > > > > It does now delay and retry the write upon an error. > > > > Regards > > Thorsten > > > > On 09.05.2013, at 16:43, treeceg <photo@> wrote: > > > > > I'm happy to run tests for you, but I'm seeing that it's not consistent. A file that errors out, can be run back through another time, and won't create an error. It is not a high percentage of errors, but with the error point being contained within a single GC command, I am having a hard time recovering from it automatically when it does happen. > > > > > > I am guessing that the variable nature is due to the files residing on a server, rather than the local disk, and so Finder response times are more variable. > > > > > > One of my machines is running 8.6 build 1203, and it seems to recover from it better on it's own, than version 8.2 which is what I have running in production, but is creating a bunch of temp files on the desktop, which is challenging to clean up as well. > > > > > > Greg > > > > > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > > > > > > > > Hello, > > > > > > > > hmm, maybe I can add a delay to my source and try to rewrite the file. Can we try that? > > > > > > > > Thorsten > > >

[thorstenlemke]

Hello Greg,yes, I just wait one second and retry.Thorsten On 10.05.2013, at 18:06, "treeceg" <photo@4miledesign.com> wrote:   With the behavior change you made, Thorsten, at what point in that sequence does it now write the original and modified files to the desktop? Does it delay and retry once, and then write out the files if the retry fails? Greg

[treeceg]

And it retries just once, and then moves on? Is that correct? --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hello Greg, > > yes, I just wait one second and retry. > > Thorsten > > > On 10.05.2013, at 18:06, "treeceg" <photo@...> wrote: > > > With the behavior change you made, Thorsten, at what point in that sequence does it now write the original and modified files to the desktop? Does it delay and retry once, and then write out the files if the retry fails? > > > > Greg > > >

[thorstenlemke]

Hello,yes, correct. Normally 1 second should be enough for the file system to close everything - the same did solve an issue with the deletion of temporary files.Thorsten On 11.05.2013, at 03:20, "treeceg" <photo@4miledesign.com> wrote:   And it retries just once, and then moves on? Is that correct? --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hello Greg, > > yes, I just wait one second and retry. > > Thorsten > 

[treeceg]

I've been running this same build (1211) for a couple weeks on one machine now. Sometimes I get a tremendous buildup of the temporary files on the desktop, and sometimes it will go for a couple days without leaving any temporary files on the desktop. When I say temporary files on the desktop, I'm referring to copies of the file with the full file name of the image, not the gc_ temp files that appear in the folder with the original itself. To refresh memories, the files I'm processing are on a server volume, that is mounted on the desktop of the client that is running the script. Overall, it has been processing files successfully, but every once in a while, it has the same behavior, where the 'set file iptc' command will hang up in mid process, and leave both the original file, as well as the temp file open, and unable to be deleted (because finder thinks they are in use). That is the scenario that is difficult to recover from automatically. It seems as though variability in response time between server and client must be a factor, though I have no direct evidence of that yet. I will grab the latest beta, and load that up and run it for a while. I appreciate the effort you've put into it so far. --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hello, > > yes, correct. Normally 1 second should be enough for the file system to close everything - the same did solve an issue with the deletion of temporary files. > > Thorsten > > > On 11.05.2013, at 03:20, "treeceg" <photo@...> wrote: > > > And it retries just once, and then moves on? Is that correct? > > > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > > > > > > Hello Greg, > > > > > > yes, I just wait one second and retry. > > > > > > Thorsten > > > > > > > > > >