• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
New Problem with recursion and timing and the finder updates
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

New Problem with recursion and timing and the finder updates


  • Subject: New Problem with recursion and timing and the finder updates
  • From: "Marc S.A. Glasgow" <email@hidden>
  • Date: Tue, 18 Feb 2003 19:07:45 -0500

I've been working on a rewrite of RecursiveRenamer (revision for OS X), an old utility of mine that runs through nested folders and renames the files therein by the folder name & index count (i.e. - folder named "bob" filled with miscellaneously named jpgs becomes filled with Bob 1.jpg, Bob 2.jpg, etc). The modifications for OS X have been minor, since the original code was quite robust (such as adding 'without invisibles' to list folder commands), but I've run into a couple problems with recursion multithreading, timing and finder updating, to wit:

1. Finder Name updating. The code renames all files within a folder to a temporary name (randomly generated string) before renaming them to the final name. This is done to ensure that there will be no naming conflicts during the final renaming process (since in our example Bob 2.jpg may already exist). The problem is that the finder's filing system seems to take it's merry old time about actually updating it's state memory of what the current filenames are, and even with a mandatory update at each instance of file renaming (accomplished with Jon's commands -- thanks Jon!):

Tell app "Finder"
update NewPathFileName with necessity
end tell

It often starts to fail this around 85+ files into the process, as if overwhelmed, especially if the call is occurring multiple times concurrently because of spawning recursions. If I don't call the update with necessity, then it doesn't update in a reliable manner at all under 10.2.x. So the question is, is there a way to ensure that either (a) Finder gets enough time to update the files, or better, (b) that a spawned recursion process completes before returning to the prior instance, or even better yet (c) is there a way to force the finder to update all of the files in a nested hierarchy or disk at a single time after all the renaming is complete?

2. How do I force the initial handler instant to end on an error situation that's in a segment of a spawned recursion? Different actions within the handler are now surrounded by try/on error/end try (which is how I tracked down the issue to begin with), and often it is a multiply spawned recursion that generates the error within it's code, so canceling it doesn't stop the prior instant, which can still be chugging away at files in vain.

Any insight helpful. I'd post the entirety of the code, but it's exceptionally long and can be tedious to follow even with the comments in place.

=-= Marc Glasgow
_______________________________________________
applescript-users mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/applescript-users
Do not post admin requests to the list. They will be ignored.

  • Follow-Ups:
    • Re: New Problem with recursion and timing and the finder updates
      • From: Andrew Oliver <email@hidden>
  • Prev by Date: Re: applescript-users digest, Vol 3 #1345 - 16 msgs
  • Next by Date: How do I script "Hide Toolbar" in Finder
  • Previous by thread: Re: applescript-users digest, Vol 3 #1345 - 16 msgs
  • Next by thread: Re: New Problem with recursion and timing and the finder updates
  • Index(es):
    • Date
    • Thread