applescript error handling? tmp file reference?

[treeceg]

Got it. Thanks. I had to put us back in production mode for the day, and I'm traveling tonight, so I won't be able to do much testing until tomorrow or the next day. I will update when I've gotten new data for you. --- In gcmac@yahoogroups.com, Christopher Stone <listmeister@...> wrote: > > On May 03, 2013, at 03:31, treeceg <photo@...> wrote: > > The links to the beta don't seem to be right. Can't locate the zip file. > > ______________________________________________________________________ > > Change .zip to .dmg in the url. > > -- > Best Regards, > Chris >

[thorstenlemke]

Hi,oh - sorry. I fixed it now.Thorsten- On 03.05.2013, at 11:13, Christopher Stone <listmeister@thestoneforge.com> wrote:   On May 03, 2013, at 03:31, treeceg <photo@4miledesign.com> wrote: > The links to the beta don't seem to be right. Can't locate the zip file. __________________________________________________________ Change .zip to .dmg in the url. -- Best Regards, Chris

[treeceg]

Thanks, Thorsten. I put the beta in place last night, but have not yet seen an error come up to be able to grab console data. I've added some additional error handling to try to make sure files are cleanly available to GC when commands are issued. Maybe that's helping some, but volume of files is also lower on the weekend. If my script sends a set file iptc command, is there any good way to recover from that if it fails? The underlying problem is that if that command fails, I'm left with an open temp file that GC is trying to do something with. In 8.6, does GC recover from that automatically, and that's why the two new files show up on my desktop (as mentioned in a previous post)? Speaking of the two files that show up on the desktop, is there a way to control where they are created? I don't see a preference that looks like it controls that location. --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hi, > > oh - sorry. I fixed it now. > > Thorsten > - > > On 03.05.2013, at 11:13, Christopher Stone <listmeister@...> wrote: > > > On May 03, 2013, at 03:31, treeceg <photo@...> wrote: > > > The links to the beta don't seem to be right. Can't locate the zip file. > > > > __________________________________________________________ > > > > Change .zip to .dmg in the url. > > > > -- > > Best Regards, > > Chris > > > > >

[thorstenlemke]

Hello Chris,sorry, you can't define this, yet.Can I get the error from the console?Thorsten On 05.05.2013, at 17:12, "treeceg" <photo@4miledesign.com> wrote:   Thanks, Thorsten. I put the beta in place last night, but have not yet seen an error come up to be able to grab console data. I've added some additional error handling to try to make sure files are cleanly available to GC when commands are issued. Maybe that's helping some, but volume of files is also lower on the weekend. If my script sends a set file iptc command, is there any good way to recover from that if it fails? The underlying problem is that if that command fails, I'm left with an open temp file that GC is trying to do something with. In 8.6, does GC recover from that automatically, and that's why the two new files show up on my desktop (as mentioned in a previous post)? Speaking of the two files that show up on the desktop, is there a way to control where they are created? I don't see a preference that looks like it controls that location.

[treeceg]

OK, I just had an image that hung it up on the set file iptc: 5/5/13 5:25:11.193 PM GraphicConverter[7984]: Error during insertion of JPEG metadata - files are stored onto the desktop 5/5/13 5:25:11.193 PM GraphicConverter[7984]: Error code: -61 , written 0 of 1657279 Does that help figure out what is happening? Can the location of where the files get stored, be set/controlled at all? Other than the desktop? Greg --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hello Chris, > > sorry, you can't define this, yet. > > Can I get the error from the console? > > Thorsten > > > On 05.05.2013, at 17:12, "treeceg" <photo@...> wrote: > > > Thanks, Thorsten. I put the beta in place last night, but have not yet seen an error come up to be able to grab console data. I've added some additional error handling to try to make sure files are cleanly available to GC when commands are issued. Maybe that's helping some, but volume of files is also lower on the weekend. > > > > If my script sends a set file iptc command, is there any good way to recover from that if it fails? The underlying problem is that if that command fails, I'm left with an open temp file that GC is trying to do something with. In 8.6, does GC recover from that automatically, and that's why the two new files show up on my desktop (as mentioned in a previous post)? > > > > Speaking of the two files that show up on the desktop, is there a way to control where they are created? I don't see a preference that looks like it controls that location. > > >

[thorstenlemke]

Hi,-61 is a write permission error. So, the file system did not allows writing the changes.Thorsten On 06.05.2013, at 01:29, "treeceg" <photo@4miledesign.com> wrote:   OK, I just had an image that hung it up on the set file iptc: 5/5/13 5:25:11.193 PM GraphicConverter[7984]: Error during insertion of JPEG metadata - files are stored onto the desktop 5/5/13 5:25:11.193 PM GraphicConverter[7984]: Error code: -61 , written 0 of 1657279 Does that help figure out what is happening? Can the location of where the files get stored, be set/controlled at all? Other than the desktop? Greg

[treeceg]

OK, so help me sort through what might be happening. When I got that error yesterday. I stopped my script and restarted it, and the file processed through without re-generating an error, so I don't think it's an actual permissions problem. The set file iptc command is the first command in the script that attempts to do any write operation on the file. Is it most likely that the finder still has the file open? Is that error number returned to the script, if I capture errors in my try block? That would at least help me deal with it when it comes up. I'll experiment with that tonight. --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hi, > > -61 is a write permission error. So, the file system did not allows writing the changes. > > Thorsten > > > On 06.05.2013, at 01:29, "treeceg" <photo@...> wrote: > > > OK, I just had an image that hung it up on the set file iptc: > > > > 5/5/13 5:25:11.193 PM GraphicConverter[7984]: Error during insertion of JPEG metadata - files are stored onto the desktop > > 5/5/13 5:25:11.193 PM GraphicConverter[7984]: Error code: -61 , written 0 of 1657279 > > > > Does that help figure out what is happening? > > > > Can the location of where the files get stored, be set/controlled at all? Other than the desktop? > > > > Greg > > >

[thorstenlemke]

Hello,hmm, maybe a previous process does still hold it open? What happens if you add a delay command to your script?Thorsten On 06.05.2013, at 22:48, "treeceg" <photo@4miledesign.com> wrote:   OK, so help me sort through what might be happening. When I got that error yesterday. I stopped my script and restarted it, and the file processed through without re-generating an error, so I don't think it's an actual permissions problem. The set file iptc command is the first command in the script that attempts to do any write operation on the file. Is it most likely that the finder still has the file open? Is that error number returned to the script, if I capture errors in my try block? That would at least help me deal with it when it comes up. I'll experiment with that tonight. --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hi, > > -61 is a write permission error. So, the file system did not allows writing the changes. > > Thorsten > 

[treeceg]

The only previous process possible is that a file is still copying into the folder the script watches. I currently check the file's modification date, with a built-in age of 20 seconds, as well as a file size check with a built in delay, to determine that the file is not still being written to by the finder. Once those two checks pass, then GC gets the file to work with. Thanks for your help so far. I'll continue to work on it, and see if I can trap that error number for my script to use to make decisions. Is there any possibility that the two files created on the desktop when an error occurs, can be controlled to be located somewhere else? I'll have to write a clean-up routine for them, but would prefer a settable location for temp/recovery files. --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@...> wrote: > > Hello, > > hmm, maybe a previous process does still hold it open? What happens if you add a delay command to your script? > > Thorsten > > > On 06.05.2013, at 22:48, "treeceg" <photo@...> wrote: > > > OK, so help me sort through what might be happening. When I got that error yesterday. I stopped my script and restarted it, and the file processed through without re-generating an error, so I don't think it's an actual permissions problem. The set file iptc command is the first command in the script that attempts to do any write operation on the file. Is it most likely that the finder still has the file open? > > > > Is that error number returned to the script, if I capture errors in my try block? That would at least help me deal with it when it comes up. I'll experiment with that tonight. > > > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > > > > > > Hi, > > > > > > -61 is a write permission error. So, the file system did not allows writing the changes. > > > > > > Thorsten > > > >

[treeceg]

In GC 8.2, what would a console error of -47 be indicating? 5/7/13 3:26:23.624 PM [0x0-0x62a62a].com.lemkesoft.graphicconverter: [GC] Deleting of file /Volumes/Editorial/zzDTI_Image_Drop/gc_8_tmp.jpg failed with error -47 This could be another clue for me, even though it's in an older version of GC. The temp file it references appears to be a complete file. I can open it up normally. For whatever reason, GC was not able to delete it, even though it had just created it as part of the set file iptc command. Greg --- In gcmac@yahoogroups.com, "treeceg" <photo@...> wrote: > > The only previous process possible is that a file is still copying into the folder the script watches. I currently check the file's modification date, with a built-in age of 20 seconds, as well as a file size check with a built in delay, to determine that the file is not still being written to by the finder. Once those two checks pass, then GC gets the file to work with. > > Thanks for your help so far. I'll continue to work on it, and see if I can trap that error number for my script to use to make decisions. > > Is there any possibility that the two files created on the desktop when an error occurs, can be controlled to be located somewhere else? I'll have to write a clean-up routine for them, but would prefer a settable location for temp/recovery files. > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > > > > Hello, > > > > hmm, maybe a previous process does still hold it open? What happens if you add a delay command to your script? > > > > Thorsten > > > > > > On 06.05.2013, at 22:48, "treeceg" <photo@> wrote: > > > > > OK, so help me sort through what might be happening. When I got that error yesterday. I stopped my script and restarted it, and the file processed through without re-generating an error, so I don't think it's an actual permissions problem. The set file iptc command is the first command in the script that attempts to do any write operation on the file. Is it most likely that the finder still has the file open? > > > > > > Is that error number returned to the script, if I capture errors in my try block? That would at least help me deal with it when it comes up. I'll experiment with that tonight. > > > > > > --- In gcmac@yahoogroups.com, Thorsten Lemke <lemke@> wrote: > > > > > > > > Hi, > > > > > > > > -61 is a write permission error. So, the file system did not allows writing the changes. > > > > > > > > Thorsten > > > > > > >