Fetch Softworks

close a specific Fetch window (15 posts)

• Started 8 years ago by Jim Brandt
• Latest reply 8 years ago from Jim Matthews

• Jim Brandt Member

  Jim,

  I'm working on a script that is attached to a Folder Action folder that accepts dropped plist files that contain the information to send one or more files to an FTP site described in the plist file. The plist file has the list of files, the FTP information (address, user ID, password, etc.) along with some other information the script needs.

  The reason I'm doing this is to allow multiple uploads to be going simultaneously, one for each dropped plist file.

  My issue is this. I have upload one going when upload two starts. Upload one finishes first, but the Fetch window for upload one doesn't close until upload two has finished and upload two's window is closed.

  In the script, I'm addressing each transfer window by it's transfer window ID obtained when I first log in. So to close then window, I'm issuing the command:

  tell application "Fetch" to tell transfer window ID IDNumber to close

  where IDNumber is the ID obtained when I first logged into the FTP site. However, the window isn't closing when this command is issued. It's waiting for the second transfer to finish before that happens.

  I was able to correctly transfer to both sites independently and get stats for each transfer independently. The only thing I can't seem to do is close the first transfer window and finish the script until the second transfer completes and finishes up.

  Any ideas as to what I need to do to make this window close? Does it need to be the frontmost window to close it? If so, how do I make this window the frontmost window.

  would:
  Set index of transfer window IDNumber to 1
  do this? Is it necessary?

  TIA,

  Jim

  Posted 8 years ago #

• Jim Matthews Administrator

  Hi,

  Usually when you control Fetch with AppleScript each AppleScript statement has to finish before the next one is executed. So if you said

  download remote file "file1.txt"
  download remote file "file2.txt"
  close transfer window 1

  the second download would not start until the first one was done, and the transfer window wouldn't be closed until the second download was done.

  But you mention that you have multiple uploads happening simultaneously. Are you using the "immediate return" parameter on your upload commands? That lets you start an upload and then immediately do something else (like start another upload).

  It might help for me to see the actual AppleScript. If you'd like me to take a look you can send it to bugs@fetchsoftworks.com .

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 8 years ago #

• Jim Brandt Member

  Jim,

  Yes, I understand in the normal script environment, if I was to start a transfer, it would have to finish before the next line in the script is executed. I've been operating like that for two years.

  In this instance, I using an Apple Action folder that has a script attached to it. When I drop a plist file containing some data, the script is invoked. The purpose of that script is to upload the file described in the plist to an FTP site also described in the same plist file. That counts as a single upload. Once the upload is done, the script sends out an email to email addresses also defined in the plist file.

  This script works flawlessly if only working on one plist file at a time.

  When I drop a second plist file into the same folder after dropping the first one, the script is invoked again, with new data (different plist), and a second upload is started. If they are both going at the same time, and the first transfer completes, the script running the first transfer hangs until the second transfer completes and the second script finishes up.

  Since it is effectively two scripts running at the same time, independently of each other, why does the first Fetch need to wait until the second Fetch is complete before it is able to close it's window and finish the script. The transfer, and the retrieval of stats all work, just not the close of the Fetch window, which then holds up the remainder of the first invocation of the script.

  If I can get this to work, I want to be able to drop 10 to 20 plist files into the watch folder more or less at the same time and have all the files transfer simultaneously. But if I can't figure out why Fetch isn't closing it's window when other Fetch Transfer windows are open, I won't be able to make this work.

  Jim

  Posted 8 years ago #

• Jim Matthews Administrator

  Ah, thanks, I think I understand what you're doing now.

  Of the top of my head I can't think of a reason why the second script's upload would interfere with the first script's ability to close a window. But I haven't done a lot of testing with simultaneous scripts, so there could be an issue that I'm not familiar with. I'll do some investigating.

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 8 years ago #

• Jim Brandt Member

  Under a "normal" transfer, if you try to close the window, Fetch reminds you that a transfer in happening and prompts about closing the window. Could it be that because the transfer in window two is on-going, that window one can't close thinking the second transfer applies to the first window?

  Just a thought. Grasping at straws.

  Thanks for looking.

  Jim

  Posted 8 years ago #

• Jim Matthews Administrator

  As a test I wrote two scripts that look like this:

  tell application "Fetch"
  set tw to make new transfer window at beginning with properties {url:myURL1}
  put into tw item myFile1
  close tw
  end tell

  tell application "Fetch"
  set tw to make new transfer window at beginning with properties {url:myURL2}
  put into tw item myFile2
  close tw
  end tell

  I started the first one, waited until the upload was about half done, and then started the second one. The first script finished, closing its transfer window, before the second upload finished.

  So it appears to be possible for one script to close a transfer window while another script is uploading, at least in some cases. The question is why it happening in your tests.

  I'll try testing with a folder action script, to see if that makes a difference.

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 8 years ago #

• Jim Brandt Member

  Unfortunately, my script isn't that simple. Each step is a handler.

  Step one logs in to the FTP site. It returns the connection status and the transfer window ID.

  Step two checks to see if there is a sub folder that needs connected to. If, so, it sets the connected directory. Again, using the transfer window ID.

  Step three transfers a file, again using the transfer window ID.

  Steps two and three are repeated for each file to be sent. (I'm sending TV commercials to TV stations. Sometimes, an SD file goes to a different directory than an HD file. Thus the directory changes).

  When all files are transferred, I close the transfer window, using the transfer window ID. Then I send an email to the station with the upload information. It's this close that hangs on the first transfer when a second transfer is still in progress.

  So, it's not all nicely done in a single tell block. I might be able to redo the script so that it could be, but there are several different combinations of one or two files, multiple or single directories, no directory, etc. that would make it a complicated single tell block.

  I appreciate you looking into this.

  Jim

  Posted 8 years ago #

• Jim Matthews Administrator

  I apologize that I've been quiet this last week. I haven't forgotten about this, and I'm still working on it.

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 8 years ago #

• Jim Brandt Member

  That's quite all right. I've been working on more important fires this week also.

  Your example has given me some ideas about shortening the whole process into a handler that prepares all the data and destination ahead of time and does the transfers in a single tell block, rather than calling handler after handler to login, change directories and send the file(s).

  I just haven't had time to get back to it.

  Thanks for keeping it in mind though. I'll keep you posted if I get a solution also.

  Jim

  Posted 8 years ago #

• Jim Matthews Administrator

  Here's a test folder action script I tried (I've replaced the actual URLs with placeholders):

  property destinationURL1 : "ftp://user1:@hostname1/path1/"
  property destinationURL2 : "ftp://user2:@hostname2/path2/"

  on adding folder items to this_folder after receiving added_items
  set firstItem to item 1 of added_items
  set firstItemName to name of (info for firstItem)
  if firstItemName is "BBEdit_10.5.4.dmg" then
  set destinationURL to destinationURL1
  else
  set destinationURL to destinationURL2
  end if
  tell application "Fetch"
  activate
  with timeout of 36000 seconds
  set tw to make new transfer window at beginning with properties {url:destinationURL}
  put into tw item added_items
  close tw
  end timeout
  end tell
  end adding folder items to

  The idea is that it uploads the items that are dropped in the folder to one of two URLs, depending on what file is dropped. I tested this script by dropping one file in the folder, and then -- while the first file was being uploaded -- I dropped another file that was meant for the other destination URL. I observed a slightly different problem than you've reported. In my tests the second drop was ignored altogether.

  In your tests the script runs to process plist files that you drop after the first one, right?

  Thanks,

  Jim Matthews
  Fetch Softworks

  Posted 8 years ago #

• Jim Brandt Member

  Yes, my second dropped file worked. The files I'm dropping are .plist files that describe the FTP credentials and the file path. My script decodes the information in the plist file to build a Fetch upload profile and starts the upload. When the upload is complete, it sends an email to the owner of the FTP site that the file is there (addresses also described in the plist file).

  Both uploads happened. The first dropped file completed before the second file upload, but the Fetch window (and the rest of the script) for the first file upload didn't close and the script didn't finish until after the second activation of the script completed, even though the second file took longer to upload.

  I plan on dropping up to forty or fifty .plist files into this watch folder, one at a time, and was wanting each dropped file to upload one or two files to a destination and send an email to that destination that the files are there. It was an attempt to get multiple uploads going simultaneously. I can't have each one held up by the previous though.

  Jim

  Posted 8 years ago #

• Jim Brandt Member

  Jim,

  A thought hit me today as I was testing an iteration of my watch folder FTP script.

  I'm using the same login (a test FTP site) with different subfolders to represent my two "different" sites.
  Could the fact that it's the same home login for both FTPs that would keep transfer window 1 from closing until transfer window 2 is complete?

  Now I need a second FTP test site...

  Jim

  Posted 8 years ago #

• Jim Matthews Administrator

  It could be that the second upload is trying to re-use the first window, depending on the way the script is written. If you have a second test site, or a second account on the same server, that would be a more realistic test.

  Jim Matthews
  Fetch Softworks

  Posted 8 years ago #

• Jim Brandt Member

  Jim,

  An update.

  I changed my routine to allow the entire Fetch process to be used from within a single tell block. Where before, I was logging using a handler, changing remote directories using a handler, uploading using a handler and getting the stats after the transfer was complete using a handler, I now do all the processing for an individual upload in one tell block.

  When I tested this on a Mac Pro, running Mountain Lion, I was able to get two simultaneously running Fetch uploads going at the same time.

  Then, we bought a Mac Mini, to be put at our server farm, to do all our uploading. I put the script, and watch folder on it, and was controlling it remotely. It came with Yosemite installed. I'm back to single stream uploads.

  I an upload is going, the second upload will wait until the first one is complete before it will run.

  I THINK it has something to do with OS X not allowing the same script to be opened twice at the same time. Or maybe it's a bug that Apple hasn't caught onto yet. Don't know. But, since I can't get more than one execution of the script to startup at the same time, I don't have the problem of script one not closing until script two is complete anymore, because there isn't a script two running. :(

  Even though I am still single streaming the uploads, the drop folder provides a partial automation, in that each upload is initiated by a dropped .plist file in the watch folder. I move the files out of the watch folder into a "processing" folder as they upload, and to a "completed" folder when they are done or an "incomplete" folder if they error out. We and check on progress and errors by a simple look at each of the folders and resends are as simple as moving a plist file back into the main watch folder.

  Thanks anyways for spending time on this "problem". It was a good excerise for me in pointing out the inefficiencies of the method I was using.

  I have another question, but it warrants a new topic.

  Jim Brandt

  Posted 8 years ago #

• Jim Matthews Administrator

  Thanks for that update. It is curious that you could get simultaneous transfers going on one Mac and not another. I don't know if that's a Mountain Lion - Yosemite difference, or something else.

  Thanks again,

  Jim Matthews
  Fetch Softworks

  Posted 8 years ago #